Instructor: Dr.

Syed Ali Raza

Department of Computer Science
GC University Lahore

Software
Chapter 5: Understanding
Requirements
Understanding Requirements
• Understanding the requirements of a problem is among the
most difficult tasks that face a software engineer.

• When you first think about it, developing a clear

understanding of requirements doesn’t seem that hard.

• After all, doesn’t the customer know what is required?

• Surprisingly, in many instances the answer to these questions is
“No.”
Understanding Requirements
• It’s your worst nightmare.

• A customer walks into your office, sits down, looks you

straight in the eye, and says,
• “I know you think you understand what I said, but what you don’t
understand is what I said is not what I meant.”
• Invariably, this happens late in the project, after deadline commitments have
been made, reputations are on the line, and serious money is at stake.
Requirements engineering
Requirements engineering is the process of establishing
l the services that the customer requires from a system

l the constraints under which it operates and is developed

Requirements
The descriptions of the system
services and constraints
that are generated during the
requirements engineering
process
What is a requirement?
• It may range from a high-level abstract statement of a
service or of a system constraint to a detailed mathematical
functional specification
• This is inevitable as requirements may serve a dual
function
• May be the basis for a bid for a contract - therefore must be open
to interpretation
• May be the basis for the contract itself - therefore must be
defined in detail
• Both these statements may be called requirements
Types of requirement
• User requirements
• Statements in natural language plus diagrams of the services the system
provides and its operational constraints.
• Written for customers
• System requirements
• A structured document setting out detailed descriptions of the system
services.
• Written as a contract between client and contractor
• Software specification
• A detailed software description which can serve as a basis for a design or
implementation.
• Written for developers
Types of Requirements: 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.
• 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 (ORDER_ID) which the user shall be
able to copy to the account’s permanent storage area.
Requirements imprecision
• Problems arise when requirements are not precisely stated.
• Ambiguous requirements may be interpreted in different ways by
developers and users.
• The system shall provide appropriate viewers for the user to read
documents in the document store.
• Consider the term ‘appropriate viewers’
• User intention - special purpose viewer for each different document type;
• Developer interpretation - Provide a text viewer that shows the contents of the
document.
Example of Ambiguity in
Requirements
• The system must provide the ability to create appointments and
appointment invitations must be sent to clients.
• The product shall provide status messages at regular intervals not
less than every 60 seconds.
Requirements completeness and consistency

• In principle, requirements should be both complete and consistent.

• Complete
• They should include descriptions of all facilities required.
• Consistent
• There should be no conflicts or contradictions in the descriptions of the
system facilities.
• In practice, it is very difficult to produce a complete and consistent
requirements document.
Types of Requirements: Non-
Functional Requirements
• Non-functional requirements
• constraints on the services or functions offered by the system such as
timing constraints, constraints on the development process, standards, etc.
• Process requirements may also be specified mandating a particular CASE system,
programming language or development method
• Non-functional requirements may be more critical than functional requirements. If
these are not met, the system is useless
Some Examples of NFRs
• -ilities:
• understandability, usability, modifiability, inter-operability, reliability, portability,
dependability, flexibility, availability, maintainability, scalability, (re-)configurability,
customizability, adaptability, stability, variability, volatility, traceability, verifiability,
predictability, compatibility, survivability, accessibility, …
• -ities:
• security, simplicity, clarity, ubiquity, integrity, safety, modularity, …
• -ness:
• user-friendliness, cost effectiveness, robustness, timeliness, responsiveness, correctness,
completeness, conciseness, cohesiveness, …
• …and there are many more:
• convenience, comfort, performance, efficiency, accuracy, precision, esthetics, consistency,
coherence, fault tolerance, self-recovery, autonomy, development time, time-to-market, …
Requirements Engineering
• Inception—ask a set of questions that establish …
• basic understanding of the problem
• the people who want a solution
• the nature of the solution that is desired, and
• the effectiveness of preliminary communication and collaboration between the customer and the
developer
• Elicitation—elicit requirements from all stakeholders
• Elaboration—create an analysis model that identifies data, function and behavioral
requirements
• Negotiation—agree on a deliverable system that is realistic for developers and customers
Requirements Engineering
• Specification—can be any one (or more) of the following:
• A written document
• A set of models
• A formal mathematical
• A collection of user scenarios (use-cases)
• A prototype
• Validation—a review mechanism that looks for
• errors in content or interpretation
• areas where clarification may be required
• missing information
• inconsistencies (a major problem when large products or systems are engineered)
• conflicting or unrealistic (unachievable) requirements.
• Requirements management
Inception
• Identify stakeholders
• “who else do you think I should talk to?”
• Recognize multiple points of view
• Work toward collaboration
• The first questions
• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution that you need?
Eliciting Requirements
• meetings are conducted and attended by both software engineers and customers
• rules for preparation and participation are established
• an agenda is suggested
• a "facilitator" (can be a customer, a developer, or an outsider) controls the meeting
• a "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic
bulletin board, chat room or virtual forum) is used
• the goal is
• to identify the problem
• propose elements of the solution
• negotiate different approaches, and
• specify a preliminary set of solution requirements
Eliciting Requirements
Conduct FA ST
meetings

Make lists of
functions, classes

Make lists of
constraints, etc.

formal prioritization?
Elic it requirement s
yes no

Use QFD to informally define actors

prioritize prioritize
requirements requirements

draw use-case
write scenario
diagram

Create Use-cases
complete template
Elicitation Work Products
• a statement of need and feasibility.
• a bounded statement of scope for the system or product.
• a list of customers, users, and other stakeholders who participated in
requirements elicitation
• a description of the system’s technical environment.
• a list of requirements (preferably organized by function) and the
domain constraints that apply to each.
• a set of usage scenarios that provide insight into the use of the system
or product under different operating conditions.
• any prototypes developed to better define requirements.
Building the Analysis Model
• Elements of the analysis model
• Scenario-based elements
• Functional—processing narratives for software functions
• Use-case—descriptions of the interaction between an “actor” and the system
• Class-based elements
• Implied by scenarios
• Behavioral elements
• State diagram
• Flow-oriented elements
• Data flow diagram
Use-Cases
• A collection of user scenarios that describe the thread of usage of a system
• Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in
some way
• Each scenario answers the following questions:
• Who is the primary actor, the secondary actor (s)?
• What are the actor’s goals?
• What preconditions should exist before the story begins?
• What main tasks or functions are performed by the actor?
• What extensions might be considered as the story is described?
• What variations in the actor’s interaction are possible?
• What system information will the actor acquire, produce, or change?
• Will the actor have to inform the system about changes in the external environment?
• What information does the actor desire from the system?
• Does the actor wish to be informed about unexpected changes?
Use-Case Diagram
Arms/ disarms
system

Accesses system sensors

via Internet

homeowner

Responds to
alarm event

Encounters an
error condition

system Reconfigures sensors

administrator and related
system features
Class Diagram
From the SafeHome system …

Sensor

name/id
type
location
area
characteristics

identify()
enable()
disable()
reconfigure()
State Diagram
Reading
Commands
State name
System status = “ready”
Display msg = “enter cmd”
Display status = steady
State variables

Entry/subsystems ready
Do: poll user input panel
Do: read user input
Do: interpret user input State activities
Analysis Patterns
Pattern name: A descriptor that captures the essence of the pattern.
Intent: Describes what the pattern accomplishes or represents
Motivation: A scenario that illustrates how the pattern can be used
to address the problem.
Forces and context: A description of external issues (forces) that can
affect how the pattern is used and also the external issues that will
be resolved when the pattern is applied.
Solution: A description of how the pattern is applied to solve the
problem with an emphasis on structural and behavioral issues.
Consequences: Addresses what happens when the pattern is applied
and what trade-offs exist during its application.
Design: Discusses how the analysis pattern can be achieved through
the use of known design patterns.
Known uses: Examples of uses within actual systems.
Related patterns: On e or more analysis patterns that are related to
the named pattern because (1) it is commonly used with the named
pattern; (2) it is structurally similar to the named pattern; (3) it is a
variation of the named pattern.
Negotiating Requirements
• Identify the key stakeholders
• These are the people who will be involved in the negotiation
• Determine each of the stakeholders “win conditions”
• Win conditions are not always obvious
• Negotiate
• Work toward a set of requirements that lead to “win-win”
Validating Requirements
• Is each requirement consistent with the overall objective for the
system/product?
• Have all requirements been specified at the proper level of abstraction?
That is, do some requirements provide a level of technical detail that is
inappropriate at this stage?
• Is the requirement really necessary or does it represent an add-on feature
that may not be essential to the objective of the system?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is, is a source (generally, a
specific individual) noted for each requirement?
• Do any requirements conflict with other requirements?
Validating Requirements
• Is each requirement achievable in the technical environment that
will house the system or product?
• Is each requirement testable, once implemented?
• Does the requirements model properly reflect the information,
function and behavior of the system to be built.
• Has the requirements model been “partitioned” in a way that
exposes progressively more detailed information about the system.
• Have requirements patterns been used to simplify the requirements
model. Have all patterns been properly validated? Are all patterns
consistent with customer requirements?