Requirements

SDLC Framework

Five Framework Activities

▪ Communication <- Requirements
▪ Planning
▪ Modeling
▪ Construction
▪ Deployment
Requirements
in one Picture
Software Requirements

Requirements – specify what to build

❑describe what, not how
❑describe the problem, not the solution
❑reflect system design, not software design
“What” vs. “how” is relative

One person’s what is another person’s how:

❑ Input file processing is the what, parsing is the how.
❑ Parsing is the what, a stack is the how.
❑ Stack is the what, a linked list is the how.
❑ A linked list is the what, Node* is the how.
Why should you care and focus on
requirements?
Benefits of eliciting requirements from customers:
▪ The #1 reason that projects succeed is user involvement
[Standish Group survey of over 8000 projects].
▪ Easy access to end users is one of three critical success factors in rapid-
development (agile) projects [Steve McConnell].

Benefits of working with customers:

▪ Good relations improve development speed.
▪ Improves perceived development speed.
▪ Customers don’t always know what they want.
▪ Customers do know what they want...it just changes over time.
How to elicit requirements?
Do:
▪ Talk to the users -- to learn how they work.
▪ Ask questions throughout the process -- "dig" for requirements.
▪ Think about why users do something in your app, not just what.
▪ Allow (and expect) requirements to change later.

Don't:
▪ Be too specific or detailed.
▪ Describe complex business logic or rules of the system.
▪ Describe the exact user interface used to implement a feature.
▪ Try to think of everything ahead of time. (You will fail!)
▪ Add unnecessary features not wanted by the customers.
Requirements: Goals and Roles
Goals when eliciting Roles when eliciting
requirements: requirements:
▪ Understand precisely what is ▪ Customers: what should be
required of the software. delivered (contractual base).
▪ Communicate this understanding ▪ Managers: scheduling and
precisely to all involved parties. monitoring (progress indicator).
▪ Control production to ensure that ▪ Designers: a spec to design the
system meets specification system.
▪ Coders: a range of acceptable
implementations.
▪ QA / Testers: a basis for testing,
verification, and validation.
Requirements Engineering
Definition. The process of eliciting, analyzing, documenting, and maintaining
requirements.
Requirements Classifications
❑ Functional requirements: Statements of services the system should provide, how
the system should react to particular inputs and how the system should behave in
particular situations.
▪ Example: input-output behavior
▪ Example (more concrete): Every order shall be allocated a unique identifier (ORDER_ID)
which the user shall be able to copy to the account’s permanent storage area.
❑ Non-functional requirements: constraints on the services or functions offered by
the system such as timing constraints, constraints on the development process,
standards, etc.
▪ Examples: security, privacy, scalability
▪ Example (more concrete): Any display of student data shall adhere to FERPA regulations.
❑ Additional constraints
▪ Examples: programming language, frameworks, testing infrastructure
Requirements Classifications
Examples
Example:
❑ Functional: A hardhat shall protect the wearer’s head from hanging equipment and
construction pieces.
❑ Non-Functional: Hardhat should must not break under 10000 PSI.

Example:
❑ Functional: A milk carton must contain a fluid.
❑ Non-Functional: The milk carton must be a cylinder and hold 32 oz of fluid.

Notice: Non-Functional requirements are constraints on functional requirements.

Functional Requirements
Examples
❑ The user shall be able to search either all the initial set of databases or select
a subset from it.
❑ The system shall provide appropriate viewers for the user to read documents
in the document store.
❑ Every order shall be allocated a unique identifier (ORDER_ID) which the user
should be able to copy to the account’s permanent storage area.

▪ “Shall” statement = a “contract” or

mandatory
▪ “Should”/“may” statement = desirable but
optional
Non-functional Classifications
❑ Product requirements
▪ Requirements which specify that the delivered product must behave in a particular way e.g.
execution speed, reliability, etc.
▪ Example: It shall be possible for all necessary communication between the APSE and the
user to be expressed in the standard Ada character set
❑ Organizational requirements
▪ Requirements which are a consequence of organizational policies and procedures e.g.
process standards used, implementation requirements, etc.
▪ Example: The system development process and deliverable documents shall conform to the
process and deliverables defined in XYZCo-SP-STAN-95
❑ External requirements
▪ Requirements which arise from factors which are external to the system and its
development process e.g. interoperability requirements, legislative requirements, etc.
▪ Example: The system shall not disclose any personal information about customers apart
from their name and reference number to the operators of the system
Strategies for eliciting
requirements
Common strategies
▪ Interviews
▪ Observations
▪ Use cases
▪ Feature list
▪ Prototyping (e.g., UI)
Bad Requirements
Bad or unclear
Example: Design a six-shot,
requirements can lead to
confusion later revolving barrel handgun
❑ Effect snowballs
❑ Unclear requirements
leads to poor design
❑ Poor design leads to
problems testing
❑ Untested software is not
useful
Challenges
❑ Unclear scope and unclear
requirements.
▪ Snowball effect
❑ Changing/evolving
requirements.
❑ Finding the right balance
(depends on customer):
▪ Comprehensible vs. detailed.
▪ Graphics vs. tables and explicit
and precise wording.
▪ Short and timely vs. complete
and late.
Challenges: Example
Natural Language is imprecise!

Example Requirement: All users have the same control

field.
▪ Is this a value all users have?
▪ Is this a format?
▪ Is there one control field for all users?
▪ Are the multiple control fields using the same information?
Common Mistakes
❑ Implementation details instead of
requirements.
❑ Projection of own models/ideas.
❑ Feature creep/bloat.
Feature creep/bloat
Feature creep: Gradual accumulation of features over time.
❑Often has a negative overall effect on a large software
project.
Why does feature creep happen?
Because features are fun!
❑Developers like to code them.
❑Sales teams like to brag about them.
❑Users (think they) want them.
Why is it bad?
❑Too many options, more bugs, more delays,
less testing, …
❑"Boiled frog" analogy.
Good Requirements
Understandable Consistent Language
▪ Technical terms confuse stakeholders
▪ Using short, declarative statements
▪ “Shall” statement = a “contract”
▪ Examples, figures, and tables for clarification
or mandatory
▪ “Should”/“may” statement =
Non-prescriptive desirable but optional
▪ Stating what customer wants, not how
programmer will do it
Correct and Complete
Concise (KIS) ▪ exhaustive list of requirements
▪ Facilitating customer’s validation of
requirements
▪ Prevents developers from skimming through
info
Requirement as User Stories
As a tenant, I can unlock the doors to enter my apartment.

user-role capability business-goal

❑ Preferred tool in agile methods.

❑ Stated in terms of user’s goals and capabilities instead of system features
❑ Written by the customer or user, not by the developer.
❑ The development effort to implement a story is estimated immediately
❑ Acceptance tests are written when the story is identified
❑ Requirements identified only for the next iteration, not for the whole
project
Example: SafeHome Identifier User Story Size

Security REQ-1 As a user, I can be sure that the doors by default will be locked. 4 points

REQ-2 As a user, I will be able to unlock the doors using a valid key. 7 points

An intruder will not be able to unlock the doors by guessing a valid key;
REQ-3 7 points
the system will block when it detects a “dictionary attack.”
❑ Note no priorities for user stories
As a user, I can be sure that the doors will be automatically locked at all
▪ Story priority is given by its order of REQ-4
times.
6 pts
appearance on the to-do list
REQ-5 The door keypad will be backlit when dark for visibility. 3 pts
❑ Estimated size points are used for REQ-6 Anyone will be able to lock the doors on demand. 3 pts
calculating project velocity (i.e.
REQ-7 As a user, I will be able to manage additional user accounts. 10 pts
size/time)
❑ Compare to IEEE-830 style REQ-8 As a user, I will be able to view the history of accesses to my home. 6 pts

requirements As a user, I will be able to configure the preferences for how my household
REQ-9 6 pts
devices will be activated on my arrival.
 Identifier User Story Size
As a host, I can take a seating request including customer party information,
Example: REQ-1 place into the seating queue, and have a table assigned or waiting time
estimated.
10
points

Restaurant REQ-2 As a waiter, I can input customer’s order. 5 points

REQ-3
Automation As a waiter, I can add special instructions to an order at the customer’s request. 2 points

REQ-4 As a waiter, I can notify the chef of the order without walking to the kitchen. 2 pts

REQ-5 As a waiter, I can view customer’s bill and enter their payment information. 7 pts
After REQ-6 As a waiter, I will be notified when an order has been completed. 2 pts

requirements REQ-7 As a chef, I can see the queue of orders waiting to be prepared. 3 pts
analysis REQ-8 As a chef, I can mark orders as “In Preparation” and “Complete”. 2 pts

As a chef, I can modify the menu to make certain dishes available or

REQ-9 6 pts
unavailable if supplies are limited.

Identifier User Story Size

REQ-2a As a waiter, I can input orders at different times for customers at the same table. 7 points
REQ-2b As a waiter, I can input different courses at different times for the same customer. 5 pts
REQ-2c As a waiter, I can input side plates after the main course is served. 2 pts
Cockburn’s requirements template
1. Purpose and scope
2. Terms (glossary)
3. Use cases (the central artifact of requirements) Our focus on next time
4. Technology used
5. Other
a) Development process: participants, values (fast-good-cheap), visibility, competition,
dependencies
b) Business rules (constraints)
c) Performance demands
d) Security, documentation
e) Usability
f) Portability
g) Unresolved (deferred)
6. Human factors (legal, political, organizational, training)
Partner Up:
smart fridge activity
Scenario: Activity
▪ Dinner/party time. ▪ 10-12 minutes
▪ On the way home. ▪ Elicitation round 1
▪ Inviting a lot of friends. ▪ Elicitation round 2 (reversed roles)
▪ Is the fridge stocked? ▪ Consolidate

Solution
▪ DIY smart fridge.
▪ Realtime data. To the activity….
▪ Mobile app.