1
>
Requirements
Dr. Anıl Koyuncu
> Software Development Life Cycle
-2 -
> Software Development Cycle
➢SDLC: produce software through a series of stages
▪From conception to end-of-life.
▪Can take months or years to complete.
➢Goals of each stage
▪ Define a clear set of steps to perform.
▪ Produce a tangible item.
▪ Allow for review of work.
▪ Specify actions to perform in the next stage.
-3 -
> The software process
➢A structured set of activities required to develop a
software system.
➢Many different software processes but all involve:
• Specification – defining what the system should do;
• Design and implementation – defining the organization of the system
and implementing the system;
• Validation – checking that it does what the customer wants;
• Evolution – changing the system in response to changing customer
needs.
4
> What is a requirement?
A statement that identifies a necessary attribute, capability,
characteristic, or quality of a system for it to have value and utility to
a stakeholder.
-5 -
> The requirements engineering process
6
> Requirement Specification
➢A requirement’s specification is a comprehensive technical
description of how that requirement will be realized.
➢The set of specifications will fully describe what the software will
do and how it will be expected to perform.
-7 -
> Specifying Requirements
➢Requirements specify what to build
• describe what, not how
• describe the problem, not the solution
• reflect system design, not software design
-8 -
> Password Requirements Specification Example
Requirement:
1. The user shall set a password to control account access.
Specification:
1.1. Password Length: The password shall be at least eight and no
more than sixteen symbols long.
1.2. Password Complexity: The password shall contain at least one
lower case and one upper case letter.
1.3. Password Storage: The password shall be hashed and stored in
the password database
1.4. Authentication Attempts: Limit the number of consecutive failed
authentication attempts to prevent brute-force attacks (e.g., no more than
100 attempts)
-9 -
> Specifying Requirements
● Requirements and their specifications are a description of what
the system should do.
● They capture what the system is doing, not how it does it.
○ How = how the code is structured, what algorithms and data structures are
used, etc.
○ (that is the design).
● Must be detailed enough to distinguish between the “right” and
“wrong” system.
- 10 -
> Importance of Requirements
➢“The single hardest part of building a software system is deciding
precisely what to build… No other part of the work so cripples the
resulting system if it is done wrong. No other part is more difficult
to rectify later.”
Fred Brooks, “No Silver Bullet”
- 11 -
> Why requirements?
➢Some goals of doing requirements:
• understand precisely what is required of the software
• communicate this understanding precisely to all development parties
• control production to ensure that system meets specs (including changes)
➢Roles of requirements
• customers: show what should be delivered; contractual base
• managers: a scheduling / progress indicator
• designers: provide a spec to design
• coders: list a range of acceptable implementations / output
• QA / testers: a basis for testing, validation, verification
> The Stakeholders
Large number of actors / stakeholders standardization
Requirements middleware organization
• different
engineersconcerns
providers
architects
• different jobs
• different skills site
• large number of tools
marketing administrators
Lawyers Security
• different software artifacts
officers
tool end users
component
component application vendors
developers
testers testers
13
> The Stakeholders
➢One requirement can have many meanings depending on the
stakeholder’s perspective.
- 14 -
> Importance of Requirements
➢The Engineering Argument:
• Engineering is about developing solutions to problems. A good solution
can only be developed if engineers understand the problem.
➢The Economic Argument:
• Errors cost more to correct the longer they go undetected.
➢The Empirical Argument:
• Failure to understand and manage requirements is the biggest single
cause of cost and schedule over-runs
- 15 -
> Types of requirement
User Requirements
➢ Properties that the user wants to see out of the final system.
➢Typically reflect what the user wants the software to make
possible in the real world.
• “The user shall be able to book a concert ticket through the system.”
➢ Usually high-level and lacking in technical detail.
➢ Gathered from the user, and form the basis for technical
requirements.
- 16 -
> Types of requirement
Hardware Requirements
➢Define the properties expected from and constraints on the
physical hardware in a system.
➢Expectations on storage space, CPU, network latency, sensor
inaccuracy bounds, etc.
- 17 -
> Example
- 18 -
> Example
- 19 -
> Types of requirement
System Requirements
➢Define how software and hardware must work together to perform
functionality.
➢Often related to interfaces, input, or output - how hardware can
influence the software.
- 20 -
> User and system requirements
21
> Functional and non-functional requirements
➢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.
• May state what the system should not do.
➢Non-functional requirements
• Constraints on the services or functions offered by the system such as timing constraints,
constraints on the development process, standards, etc.
• Often apply to the system as a whole rather than individual features or
services.
➢Domain requirements
• Constraints on the system from the domain of operation
22
> Functional and non-functional requirements
➢functional: map inputs to outputs
• "The user can search either all databases or a subset.”
• "Every order gets an ID the user can save to account storage.”
➢nonfunctional: other constraints, ilities: dependability, reusability,
portability, scalability, performance, safety, security
• "Our deliverable documents shall conform to the XYZ process.”
• "The system shall not disclose any personal user information.”
> Functional requirements
➢Describe system services or actions
➢Related to the functionality of the system.
➢Can be used to distinguish correct output from incorrect.
• What inputs the system should accept
• What outputs the system should produce
• What data the system should store that other sys might use
• What computations the system should perform
• The timing and synchronization of the above
> An example system: LIBSYS
> An example system: LIBSYS
➢A library system that provides a single interface to a number of
databases of articles in different libraries
➢Users can search for, download and print these articles for
personal study
> Examples of functional requirements
➢The user shall be able to search either all of 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 which the user
shall be able to copy to the account’s permanent storage area
> Non-functional requirements
➢These define system properties and constraints
• e.g. reliability, response time and storage requirements.
• Constraints are I/O device capability, system representations, etc.
➢Process requirements may also be specified
• mandating a particular IDE, Team organization, tool support, programming
language, or development method.
➢Non-functional requirements may be more critical than functional
requirements.
• If these are not met, the system may be useless.
28
> Non-functional requirements implementation
➢Non-functional requirements may affect the overall architecture of
a system rather than the individual components.
• For example, to ensure that performance requirements are met, you may
have to organize the system to minimize communications between
components.
➢A single non-functional requirement, such as a security
requirement, may generate a number of related functional
requirements that define system services that are required.
• It may also generate requirements that restrict existing requirements.
29
> Metrics for specifying nonfunctional requirements
Property Measure
Speed Processed transactions/second
User/event response time
Screen refresh time
Size Mbytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
30
> Non-functional classifications
➢Product requirements
• Requirements which specify that the delivered product must behave in a particular way
e.g. execution speed, reliability, etc.
➢Organisational requirements
• Requirements which are a consequence of organisational policies and procedures e.g.
process standards used, implementation requirements, etc.
➢External requirements
• Requirements which arise from factors which are external to the system and its
development process e.g. interoperability requirements, legislative requirements, etc.
31
> Types of nonfunctional requirement
32
> Non-functional classifications
What are some examples of non-functional requirements?
➢Product requirements
• Withdrawals must be available with no more than 30 minutes of maintenance time
per day.
➢Organisational requirements
• The system development process shall follow the SCRUM model.
➢External requirements
• The system shall keep a log of transactions in the Microsoft Excel file format.
33
> Non-functional classifications
What are some examples of non-functional requirements?
➢Product requirements
• The user interface for LIBSYS shall be implemented as simple HTML without
frames or Java applets.
➢Organisational requirements
• The system development process and deliverable documents shall conform to the
process and deliverables defined in XYZCo-SP-STAN-95.
➢External requirements
• The system shall not disclose any personal information about customers apart
from their name and reference number to the operators of the system
34
Examples of nonfunctional requirements in the
> LIBSYS system
Product requirement
The LIBSYS system shall be available during normal working hours
(Mon–Fri, 0830–17.30). Downtime within normal working hours shall
not exceed five seconds in any one day.
Organizational requirement
Users of the LIBSYS system shall authenticate themselves using their
library identity.
External requirement
The system shall implement the Z39.50 standard to integrate all
database.
35
> Domain requirements
➢Derived from the application domain and describe system
characteristics and features that reflect the domain
➢Domain requirements be new functional requirements, constraints
on existing requirements or define specific computations
➢If domain requirements are not satisfied, the system may be
unworkable
> Library system domain requirements
➢There shall be a standard user interface to all databases which
shall be based on the Z39.50 standard
➢Because of copyright restrictions, some documents must be
deleted immediately on arrival. Depending on the user’s
requirements, these documents will either be printed locally on the
system server for manually forwarding to the user or routed to a
network printer
> Domain requirements problems
➢Understandability
• Requirements are expressed in the language of the application domain
• This is often not understood by software engineers developing the system
➢Implicitness
• Domain specialists understand the area so well that they do not think of
making the domain requirements explicit
> Case study
➢A mental health case patient management system
• Mentcare. A system used to maintain records of people receiving care for
mental health problems.
39
> Mentcare: A mental health support system
➢This case study focuses on the requirements for a system called
the Mentcare system. The system is designed for use in clinics
attended by patients suffering from mental health problems and
records details of their consultations and conditions. It is separate
from a more general patient records system as more detailed
information has to be maintained and the system has to be set up
to generate letters and reports of different types and to help
ensure that the laws pertaining to mental health are maintained by
staff treating patients.
40
>
41
>
42
