1. SWE 3313
Requirements

2. Objectives Eliciting requirements from the customers
Modeling requirements
Reviewing requirements to ensure their quality
Documenting requirements for use by the design and test teams

3. The Requirements Process
A requirement is an expression of desired behavior
A requirement deals with
objects or entities
the state they can be in
functions that are performed to change states or object characteristics
Requirements focus on the customer needs, not on the solution or implementation
designate what behavior, without saying how that behavior will be realized

4. Why Are Requirements Important?
Top factors that caused project to fail
Incomplete requirements
Lack of user involvement
Unrealistic expectations
Lack of executive support
Changing requirements and specifications
Lack of planning
System no longer needed
Some part of the requirements process is involved in almost all of these causes
Requirements error can be expensive if not
detected early

5. Process for Capturing Requirements
Performed by the req. analyst or system analyst
The final outcome is a Software Requirements Specification (SRS) document

6. Requirements Elicitation
Customers do not always understand what their needs and problems are
It is important to discuss the requirements with everyone who has a stake in the system
Come up with agreement on what the requirements are
If we can not agree on what the requirements are, then the project is doomed to fail

7. Requirements Elicitation: Stakeholders
Clients: pay for the software to be developed
Customers: buy the software after it is developed
Users: use the system
Domain experts: familiar with the problem that the software must automate
Market Researchers: conduct surveys to determine future trends and potential customers
Lawyers or auditors: familiar with government, safety, or legal requirements
Software engineers or other technology experts

8. Means of Eliciting Requirements
Interviewing stake holders
Reviewing available documentations
Observing the current system (if one exists)
Apprenticing with users to learn about user's task in more details
Interviewing user or stakeholders in groups
Using domain specific strategies, such as Joint Application Design, or PIECES
Brainstorming with current and potential users

9. Types of Requirements Functional requirement
Describes required behavior in terms of required activities
Quality requirement or non-functional requirement
Describes some quality characteristic that the software must posses
Design constraint
A design decision such as choice of platform or interface components
Process constraint
A restriction on the techniques or resources that can be used to build the system

10. Making Requirements Testable
Fit criteria form objective standards for judging whether a proposed solution satisfies the requirements
It is easy to set fit criteria for quantifiable requirements
It is hard for subjective quality requirements
Three ways to help make requirements testable
Specify a quantitative description for each adverb and adjective
Replace pronouns with specific names of entities
Make sure that every noun is defined in exactly one place in the requirements documents

11. Resolving Conflicts
Different stakeholder has different set of requirements
potential conflicting ideas
Need to prioritize requirements
Prioritization might separate requirements into three categories
essential: absolutely must be met
desirable: highly desirable but not necessary
optional: possible but could be eliminated

12. Two Kinds of Requirements Documents
Requirements definition: a complete listing of everything the customer wants to achieve
Describing the entities in the environment where the system will be installed
Requirements specification: restates the requirements as a specification of how the proposed system shall behave

13. Characteristics of Requirements
Correct
Consistent
Unambiguous
Complete
Feasible
Relevant
Testable
Traceable

14. Project Initiation Key information to gather at project initiation:
Purpose and Description of project.
List of key stakeholders.
Who is a stakeholder?
Important Project Dates

15. Project Initiation Setting goals:
Goal setting is the most critical step in project initiation.
Goals set here, usually by the customer, will influence the requirements and design that follow.
Goals need due dates
S.M.A.R.T. Goals:
Specific
Measurable
Achievable
Relevant
Time-Limited

16. Project Initiation Additional concerns
Risk assessment
Risk scoring:
Detection Prob.
Likelihood
Severity
Equipment and software needs
Technical skills and knowledge

17. Simple Requirements: User story
What is a user story?

18. Writing User Stories User Stories:
are very slim and high-level requirements artifacts.
are small - much smaller than other requirement artifacts such as use cases or usage scenarios.
Usually no more than three to five sentences in length.
Some say that a user story should be able to fit on an index card.
Should be written in non-technical language that a non-engineer can understand.
Should avoid locking-in to any technology specifics.
e.g. language, server, database type, device type, etc.

19. Writing User Stories Sample User Stories for a College Website System
“Students can purchase semester parking passes online and shall be able to pay for their passes via credit card or PayPal. The student should receive a receipt by as well as a printed receipt and/or a temporary parking pass printout for their dashboard.”
“Students should be able to view registration information, including their current semester schedule, their unofficial transcript. Students should also be able to order official transcripts, which they can pay for via credit card or PayPal. They should receive an and printed receipt.”

20. Writing User Stories
There are several important considerations to keep in mind when writing user stories:
Stakeholders write or strongly influence user stories, or at least narrate them to the engineers who record them.
Project stakeholders write the user stories, not the developers!
User stories are simple enough that people can learn to write them in a few minutes.
Therefore, it makes sense that domain experts (the stakeholders) write them.

21. Writing User Stories Handy templates for user stories:
“As a user, I want to…” is a good template to begin with.
“As a ______ I want to _______ so that _______” is also good.
“Given [context] and [some more context]… when [event] then [outcome] and [another outcome]…”

22. Writing User Stories Each User Story should have: A unique identifier
An estimated cost
A Priority

23. Writing User Stories Each User Story should have: A unique identifier
This not only allows east reference to user stories by number, but because these user stories are a primitive form of requirement, it allows limited requirements traceability throughout the development lifecycle.

24. Writing User Stories
Unique Identifier. A “dotted” numbering system allows large, general user stories can then be decomposed easily:
1. Students can access the registration and records systems.
1.1 Students can enroll in courses.
1.2 Students can check their grades and view their transcript.
1.2.1 Students can order an official transcript

25. Writing User Stories Each User Story should have: An estimated cost
This “cost” may be in terms of size (of code), time, or money
Estimated Cost
If you don’t know specifics in terms of time, money, or size, one way to estimate is to assign ‘points’ to each story.
The points are relative indication of how long it will take to implement a articular user story compared to another.
The points can later be user to help determine specific time/cost estimates and to formulate your Management Plan.
For example, User Story 1 may be twice as difficult as Story 2, so it would get 2 points to the latter’s 1 point. If it is later determined that it takes on average 2.5 hours per point, then User Story 1 would take 5 hours to implement.

26. Writing User Stories
Each User Story should have: A Priority
Requirements are prioritized by your project stakeholders and NOT the developers.
These priorities are then used to add each user story to the project tasking in the appropriate order.
It is common to use a scale of 1 to 10 with 1 being the highest priority, but other prioritization approached are possible.
e.g. High / Medium / Low.

27. INVEST criteria for User Stories
A well-written user story follows the INVEST model
Independent - One user story should be independent of another. Dependencies between stories make planning, prioritization, and estimation more difficult. Can be reduced by combining stories or rewriting differently.
Negotiable - A user story is negotiable - just a short description which does not include details. Details are worked out later as the team discusses each story. A story with too much detail actually limits conversation.
Valuable - Each story has to be of value to the customer (which is why the customer should write them). Once a customer realizes that a user story is not a contract and is negotiable, they are more comfortable.

28. INVEST criteria for User Stories
Estimable - Developers need to be able to estimate (at a ballpark even) a user story to allow prioritization and planning of the story. Problems that can keep developers from estimating a story are: lack of domain knowledge (in which case there is a need for more conversation with the customer); or if the story is too big (in which case the story needs to be broken down into smaller stories).
Small - A good story should be small in effort, typically representing no more, than 2-3 person weeks of effort. A story which is larger than that is more likely to have errors associated with scoping and estimation.
Testable - A story needs to be testable for the verification and validation of the product to take place. We can’t develop what we cannot test. If you can't test it then you will never know when you are done. An example of non-testable story: "software should be easy to use”

29. Let’s write some user stories…
Scenario 1: ATM Machine Scenario 2: Gasoline Pump

30. User Stories In summary, a user story must:
Have a unique identifier, priority, and estimated cost.
Express desired outcomes from the point of view of the user.
Be written in clear, non-technical terms and avoid specifics of implementation.

31. User Stories
User Stories are the BEGINNING, not the end of the requirements gathering process.
Writing user stories does NOT absolve you from other forms of requirements gathering and documentation!
More formal methods, such as use cases, UML diagrams, or detailed requirements documents may need to be written…
You will likely need to generate use cases in your development cycle this semester