Requirements in Agile

ITEC 3870 Software Development II,
Anca Doloc-Mihu and Cengiz Günay

(License: CC BY-SA 4.0)

Prev - Kanban, Next - User Stories

Some slides courtesy of Joan Smith, Eugene Agichstein, and the Internets.

What is a Requirement?

Requirements are the descriptions of the services provided by a system and its operational constraints

* It is about WHAT not HOW

* It varies greatly. It may range from a high level abstract statement to a detailed mathematical specification

* It may be as complex as a 500 pages of description

Why we need requirements?

Advantages of a complete set of documented requirements

* Ensures the user (not the developer) drives system functionalities

* Helps avoiding confusion and arguments

* Helps minimizing the changes which reduces the cost

Changes in requirements are expensive.

Costs of changing the requirements

3 x as much during the design phase

5-10 x as much during implementation

10-100 x as much after release

Code Complete, p30

Requirements help reduce errors

A careful requirements process doesn’t mean there will be no changes later

Average project experiences about 25% changes in the requirements

This accounts for 70-80% if the rework of the project Code Complete, p40

Important to plan for requirements changes

Example: the case of critical applications

Different levels of abstraction

Abstract level: User requirements

* Usually the first attempt for the description of the requirements
* Includes services and constraints of the system
* Given in natural language or diagrams
* Readable by everybody, i.e. understandable by the user
* Serve business objectives

Example of User requirement:
As a user who found a new job announcement, I want to add a new position to the website so s/he can start working on doing the initial research and apply to it.

Different levels of abstraction

Not abstract level: System requirements

* Includes services and constraints of the system in detail
* Useful for the design and development
* Precise and cover all cases
* Structured presentation

Example of System requirement:
A registered user on the academic jobs website should be able to add a new position listing with the name of the school and academic unit, date of posting, date of expiry, application deadline, and contact and application details. The interaction fails if: the position is already listed, the application deadline is in the past, position announcement is expired, or the contact information is missing. If fails, point mistakes to user and ask the user to fix and resubmit.

Problems with user requirements

Can you think of any issues?

* Lack of clarity - ambiguous language

* Confusion - design information are not distinguished between functional and non-functional requirements

* Several requirements are defined as a single one

* Incompleteness – requirements may be missing

* Inconsistency – requirements may contradict themselves

Guideline to minimize issues with user requirements

* Separate functional and non-functional requirements

* Requirements must be clearly identified by a number

* Include a rationale for each requirement – this helps clarify reasoning behind the requirements and may be useful for evaluating potential changes in the requirements

* Team should decide to use a standard form/template

* Have a clear way to establish and distinguish requirements priorities

* Write test cases; requirements must be testable

* Deliverables

System requirements

* Elaborate the user requirements to get a precise, detailed and complete version of them

* Used by designers and developers

* Write system requirements using natural language

* Forms/templates and logic are used to bring some rigor, but make sure everyone understands them

Example: If sales for current month are below target sales, then report is to be printed unless difference between target sales and actual sales is less than half of difference between target sales and actual sales in previous month, or if difference between target sales and actual sales for the current month is less than 5%.

Problems: * Difficult to read * Ambiguity: 5% of what? * Incomplete: what if sales are above target sales?

Types of requirements

Functional requirements
* Services the system should provide
* What the system should do or not do in reaction to particular situations

Non-functional requirements - might be more critical than functional ones
* Constraints on the services or functions offered by the system
* Examples: Timing constraints (e.g., one semester), constraints on the development process (CASE, language, development method…), standards etc

Domain requirements
* From the application domain of the system
* May be functional or non-functional
Examples: Medicine, library, physics, chemistry

Note: You can have all of user/system functional/nonfunctional requirements.

Non-functional requirements categories

Product requirements - related to product behavior
Example: Timing, performance, memory, reliability, portability, usability

Organizational requirements related to policies and procedures in the customer’s and developer’s organizations
Example: Process requirements, implementation requirements, delivery requirements

External requirements related to factors externals to the system and the development process
Example: Interoperability, legislation, ethics

Non-functional requirements categories (cont.)

How to test non-functional requirements

It is important to be able to test/verify/check non-functional requirements

Requirement engineering

Feasibility study

  • It is done at first to decide whether or not the project is worthwhile

  • Look at different perspectives: market analysis, financial, schedule, technical, resource, legal…

  • Target is to make you aware of the risks

How to do the study

  • Consult information sources: managers, software engineers, end users…

  • Collect information from interviews, surveys, questionnaires…

Should be short (2-3 weeks)

Feasibility study

  • What if the system wasn’t implemented?

  • What are current process problems?

  • Do technical resources exist?

  • What is the risk associated with the technology?

  • Is new technology needed? What skills?

  • How will the proposed project help?

  • How does the proposed project contribute to the overall objectives of the organization?

  • Have the benefits identified with the system being identified clearly?

Feasibility study

  • What will be the integration problems?

  • What facilities must be supported by the system?

  • What is the risk associated with cost and schedule?

  • What are the potential disadvantages/advantages?

  • Are there legal issues?

  • Are there issues linked with the fact that this is an offshore project?

and more

Requirements as user stories

From requirements to user stories

Use-case Diagram

From a “use case” to “user stories”

* Use case diagram shows all things an actor can do

* Can be broken down to individual user stories

Prev - Kanban, Next - User Stories

Home