Towards developing a

software product
Brief introduction to lifecycles
and
Requirements

Requirements engineering
1
 Software Project Lifecycles
■ Projects are decomposed into phases
■ Project Lifecycle describes the project in
terms of its phases
■ Each phase
■ Produces a set of deliverables
■ Phase is finished when the deliverables
are completed

2
 Software Project Lifecycles
Software
Concept

Requirement
Analysis

Architectural
Design

Detailed
Design

Coding
src: https://commons.wikimedia.org/wiki/File:Waterfall_model.svg
& Debugging

System
Testing

Waterfall Deployment
& Maintenance

3
 Spiral Lifecycles

By Connyderivative work: Spiral_model_(Boehm,_1988).png: Marctroyderivative work: Conan (talk) -

File:Spiralmodel_nach_Boehm.png, Spiral_model_(Boehm,_1988).png, Public Domain, 4
https://commons.wikimedia.org/w/index.php?curid=9000950
 Iterative Lifecycle

By Aflafla1 - Iterative development model V2.jpg , User:Westerhoff, CC0,

https://commons.wikimedia.org/w/index.php?curid=34159246
5
 Agile Lifecycle

By Planbox - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=19543504

6
Requirements Engineering
Understanding WHAT to build

7
 Second Life Type of Avatar

https://secondlife.com/ -- Avatar selection

8
https://secondlife.com/ Linden dollars - virtual economy

9
https://www.autodesk.com/products/revit Architectural/BIM (Building Information Modeling) 10
Requirements engineering
● Process of figuring out
● Services the customer needs

● Constraints of operation

● It is about WHAT will be built!

Requirements engineering
11
Why Develop Requirements Specs?
I believe that on any non-trivial project (more than
about 1 week of coding or more than 1
programmer), if you don't have a spec, you will
always spend more time and create lower quality
code.

Joel Spolsky
http://www.joelonsoftware.com

Requirements engineering
12
Requirement
● Descriptions of
● system services
● constraints

● Gathered during the requirements

engineering process.

Requirements engineering
13
Use of Requirement Specs
● Design

● Communicate

● Test

Requirements engineering
14
Types of Requirements
● Functional
● Behavior of system
● From user's point of view
● Non-functional
● Non behavior related constraints
● Constraints on the services
●i.e timing, development process, standards,
● Apply to whole system rather than functions

Requirements engineering
15
Types of requirement
● User requirements
● Written for customers
● Natural Language
● Diagrams

● System requirements
● Detailed descriptions system functions,
services, and operational constraints.
Requirements engineering
16
Requirement Language
● Requirements are often written in natural
language (e.g., English).
● inherently ambiguous
● should be reviewed by an independent
party to identify ambiguous language so
that it can be corrected

Requirements engineering
17
Clear description
● Must be precise

● Ambiguous requirements
● Different interpretation

● How can we avoid ambiguity?

Requirements engineering
18
Guidelines for writing requirements
● Use a standard format
● Be consistent
● Use shall for mandatory requirements
● Use should for desirable requirements
● Highlight key parts
● Use structure to group related requirements
● Enumerate !!! (Why?)
Requirements engineering
19
Non-functional requirements
● System properties and constraints
● Up time
● Response time
● Storage requirements
● Usability
● Process requirements
● IDE
● Programming language
● Development method.
Requirements engineering
20
Verifiable Non-functional Requirement
Description
● Verifiable non-functional requirement
● Measurable
● Can be tested

● Difficult to state precisely

→ difficult to verify.

Requirements engineering
21
Metrics for nonfunctional requirements
Property Measure
Speed Processed transactions/second
User/event response time
Screen refresh time
Size MB, GB
Ease of use Training time
Number of help frames

Requirements engineering
22
Metrics for NF Req. (cont.)
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
% of events causing failure

Portability Number of target systems

Specific platforms

Requirements engineering
23
Good Software Requirement
Specifications (SRS)
● Correct

● Unambiguous

● Complete

● Consistent

● Ranked for importance and/or stability

● Verifiable

● Modifiable

● Traceable
Requirements engineering
24
 Correctness
● With external objects
● Incorrect descriptions of real objects
● Ex: Minimum dimensions of elevator doors
● Logical ( A x B vs A / B)
● Temporal (A after B vs A and B simultaneously)
● Note: Use consistent and precise terminology
● Agreement with terminology in a project team is crucial (Need
a Glossary)

Requirements engineering
25
Completeness & Consistency
● Should be complete & consistent
● Complete
● All required functionality is stated
● Consistent
● There are no conflicts between requirements
● In practice: Impossible, but …
must aim to achieve

Requirements engineering
26
Requirements engineering processes
● Requirements elicitation
● Requirements analysis
● Requirements validation
● Requirements management
● In practice
● iterative activity
● processes are interleaved.

Requirements engineering
27
Requirements elicitation and analysis
● Requirements discovery

● Requirements classification and organization

● Requirements prioritization and negotiation

● Requirements specification

Requirements engineering
28
Scenarios
● Scenarios are real-life examples
● Consists of
● Initial situation
● Normal flow of events
● What can go wrong
● Information about other concurrent activities
● Terminating situation
Requirements engineering
29
Use cases
● Scenario based technique in the UML

● Identifies the actors and the interaction

● A set of use cases should describe all

possible interactions with the system.

Requirements engineering
30
Requirements validation
● Do the requirements define the system that
the customer really wants?

● Requirements error is very costly

Requirements engineering
31
 Requirements checking
● Validity. Does the system provide the functions which
support customer needs?
● Consistency. Are there requirements conflicts?
● Completeness. Are all functions required by the customer
included?
● Realism. Can the requirements be implemented given
available budget/technology
● Verifiability. Can the requirements be checked?

Requirements engineering
32
Requirements validation
● Requirements reviews
● Systematic manual analysis of requirements.
● Prototyping
● Using an executable model of the system to check
requirements.
● Test-case generation
● Developing tests for requirements to check testability.

Requirements engineering
33
 Review checks
● Verifiability
● Is the requirement realistically testable?
● Comprehensibility
● Is the requirement properly understood?
● Traceability
● Is the origin of the requirement clearly stated?
● Adaptability
● Can a requirement be changed without a significant
impact on other requirements?

Requirements engineering
34
Learnings
● What software requirements are
● Elicitation
● How to write requirements
● Good practices
● Validation

Next: Towards more formal representations.

Requirements engineering
35