Software

Requirements Engineering
Lecture 3
W4H of Requirements
Today’s Agenda
 W4H of Requirements
 The Requirements Engineering Process
 Requièrent Engineering Process Models
 Problem Domain and the System/Ssoftware-to-be
 The beginning is the most important part of the work.
RE Process and Related Activities
Why?
Identify Business Needs and Goals

What?
Derive User & Functional Requirements

How? Time
Design Solutions
TIME
Who?
When? Project Management Process

If-Then Risk Management Process

Does It? Quality Management Process

Where? Component & Configuration Management Process

Summary of Paper What, Why, Who, When,
and How
 If
specific requirements are not met, the software produced
will not meet the needs of the organization.
 A discussion covers levels and types of requirements that:
 must be defined: (what);
 the benefits of having the right requirements (why);
 getting the stakeholders involved in the process (who);
 requirements activities throughout the development lifecycle (when); and
 techniques for eliciting, analyzing, specifying, and validating software requirements
(how).
ABSTRACT
 If
software requirements are not right, companies will not end up with the
software they need. This Paper discusses:

 What: The various levels and types of requirements that need to be defined
 Why: The benefits of having the right software requirements
 Who: The stakeholders of the software requirements and getting them involved in the
process
 When: Requirements activities throughout the software development life cycle
 How: Techniques for eliciting, analyzing, specifying, and validating software requirements
WHAT
 Requirements must be determined and agreed to by: The customers, users,
and suppliers of a software product before the software can be built.
 The requirements define the “what” of a software product:
 What the software must do – Functional Requirements
 The capabilities of the software
 What the software must be – Non- Functional Requirements
 The characteristics, properties, or qualities of the software
 What limitations there are on the choices
 When implementing the software.
Levels and Types of Requirements
 What information the practitioners need to elicit, analyze,
specify, and validate when they define their software
requirements.
Business Level
• Business requirements define :
• The business problems to be solved or the
business opportunities to be addressed by the
Business software product.
Requirements • Why the software product is being developed.

Typically stated in terms of the objectives of the customer

or organization
User Level
• user’s perspective of the software
functionality
User • They define what the software has to do in
Requirements order for the users to accomplish their
objectives.
Multiple user level requirements may be needed
in order to fulfill a single business requirement.
User Requirements
 For example:
 The business requirement to allow the customer to pay for gas at
the pump might translate into multiple user requirements, including
requirements for the user to:
 Swipe credit or debit card
 Enter a security PIN
 Request a receipt at the pump
Business Rules
 Business rules are:
Lists of statements that tell you whether you may or may not do something, or give you the
criteria and conditions for making a decision. 
 One factor of a business requirement is what you need to do to enable the implementation
of and compliance with a business rule.
 Business requirements  Business rules:
 Specific policies, standards, practices, regulations, and guidelines that define:
 How the users do business (and are therefore considered user-level requirements).
 The software product must adhere to these rules in order to function appropriately within
the user’s domain.
Business rule Vs Business requirement? 
 Example:  License Inspection Project
 Business Rules:
 A Driver of a Vehicle must have a valid Driver's License.
 A Driver's License must be considered valid if all of the following are true:
 The Driver's License belongs to the Driver.
 The Expiry Date of the Driver's License is later than the Inspection Date.
 The physical proof is produced within 24 hours of the Inspection Date.

 Possible business requirements to enforce these rules:

 Police officer to inspect driver's license.
 Scanner to read driver's license for validity.
 Card reader for driver to insert driver's license when driving through a checkpoint.
Quality Attributes
 Quality attributes are nonfunctional characteristics that define
 “The software product’s quality”.
 Quality attributes include:
 Reliability
 Availability
 Security
 Safety
 Maintainability
 Portability
 Usability and other properties.
User Level Control Flow
A quality attribute may translate into product-level functional requirements:
 Specify what functionality must exist to meet the nonfunctional attribute.
 Example: Ease of learning requirement might translate into the functional requirement :
 Having the system display pop-up help when the user hovers the cursor over an icon.

 A quality
attribute may also translate into product-level nonfunctional
requirements:
 Specify the characteristics the software must possess in order to meet that attribute.
 Example: an ease-of-use requirement might translate into nonfunctional requirements for
response time to user commands or report requests.

Product Level
• The software functionality must be built into the
product to enable users to accomplish their tasks.
Functional • Satisfying the business requirements.
Requirements

Multiple functional level requirements may be needed to

fulfill a user requirement

Example: The requirements that the users can swipe their credit card might
translate into multiple functional requirements including requirements for the
software to:
• Prompt the customer to put his or her card into the reader
• Detect that the card has been swiped
• Determine if the card was incorrectly read and prompt the customer to
swipe the card again
• Parse the information from the magnetic strip on the card
Product Level Requirements
 External
Interface Requirements : The requirements for the information flow across: shared interfaces to
hardware, users, and Other software applications outside the boundaries of the software product being developed.
 Constraints:​Anyrestrictions imposed on the choices that the supplier can make when designing and
developing the software. ​
 Forexample, there may be a requirement  that the completed software use no more than50 percent of available
system memory or disk space in order to ensure the ability for future enhancement. 
 DataRequirements:​The specific data items or data structures that must be included as part of the software
product. ​
 For example, a payroll system would have requirements for current and year-to-date payroll data.
 Product Requirement Document: A product requirements document (PRD) is a document written by a company
that defines a product they are making, or the requirements for one or more new features for an existing product.
Product Level Control
Flow
The software may be part of a much larger
system that includes other components.
In this case, the business and user-level
requirements feed into the product
requirements at the system level.
The system architecture allocates
requirements from the set of system
requirements downward into the software,
hardware, and manual operations
components.
Why
 The hardest part of building a software system is deciding precisely what to build. No other
part of the conceptual work is as difficult as establishing the detailed technical requirements,
including all of the interfaces to people, to machines, and to other software systems.
 No other part of the work so cripples the resulting system if done wrong.
 No other part is more difficult to rectify later”
 Fredrick Brooks

 Eliciting,
analyzing, and writing good requirements are the most difficult parts of software
engineering.
 “If you don’t get the requirements right, it doesn’t matter how well you do anything else.”
 One can end up doing a perfect job of building the wrong product.
 Karl Wiegers
Why
 Non serious Requirements surface:
 many issues that can have a negative impact on software development projects and products:
 These issues include:
 Incomplete requirements
 Lack of user involvement
 Requirements churn
 Wasted resources
 Gold plating
 Inaccurate estimates
 Incomplete Requirements
Requirements Consequences
Incomplete building a software product that does not meet all of the
Requirements
Noritaki customer
Kano developed a model of the and user’s needs
relationship between customer satisfaction and quality
requirements
Kano Model
 Expected Quality:
 The expected quality line represents those quality requirements that the customer explicitly states.
 For example, they will state their preferences for the make, model, options etc.
 Dissatisfied if not met
 Satisfaction increases  if met
 The expected quality requirements are the ones practitioners can elicit fairly easily if they talk to the product’s stakeholders.
 Basic quality requirements A customer expects the product to have
 Absence  dissatisfaction
 Exciting quality is the innovative requirements level and represents unexpected items
 it is easy to miss both the basic and exciting quality requirements if:
 Req Engr do not do a thorough job of detailed requirements elicitation and analysis or
 miss a stakeholder group or
 if they do not get the users involved in the process,
 they can end up with gaps even in their expected requirements.
Requirements Churn
Requirements Consequences
changes in the requirements after they are initially agreed to
and base lined
Change may be:
Requirements Churn
• A part of refining developers’ understanding
• Because of changes in the environment or
• The user’s needs over time that occur as a natural part
of a project.
• If requirements are poorly defined
• Missing requirements
• Poorly written or ambiguous requirements

Requirements churn can be avoided with good RE practices

Requirements Errors
Requirements Consequences
70 percent to 85 percent of the rework costs on a
software project (Wiegers)

Requirements One requirements defect if found during the requirements

Errors phase and it costs one unit to fix, the cost of fixing that same
defect will typically increase as it is found later and later in
the life cycle
Requirements Gold Plating
Requirements Consequences
when a developer adds functionality to the software
that was not in the requirements specification but that
they believe “the user will just love” without
Requirements putting that functionality through the requirements
Gold plating engineering process.

Users may or may not want the new functionality

• If they don’t, the cost of developing it is a waste
Who
 Stakeholdersare individuals who affect or are affected by the software
product and therefore have some level of influence over the
requirements for that software product.
 The requirements engineering process provides the best opportunity to consider
all of the various stakeholder’s interest in context with one another
 There are three main categories of stakeholders:
 The acquirers of the software product,
 The suppliers of the software product, and
 Other stakeholders.
Acquirers of the Software Product
Type Role

• Can be divided into two major groups.

• There are the customers who request, purchase,
Acquirer of the and/or pay for the software product in order to
software product meet their business objectives.
• The users/ end-users, who actually use the
product directly or use the product indirectly by
receiving reports, outputs, or other information
generated by the product.
Suppliers of the Software Product
Type Role
• include individuals and teams that are part of the organization that
Suppliers of the software develops the software product or are part of the organizations that
product distribute the software product or are involved in other product
delivery methods (for example, outsourcing).
• The requirements analyst/business analyst/ system analyst, is
responsible for :
• eliciting the requirements from the customers, users, and other
stakeholders,
• analyzing the requirements, writing the requirements
• specification, and communicating the requirements to
development and other stakeholders.
Suppliers of the Software Product
(cont…)
Type Role
• The designers are responsible for:
• Translating the requirements into the software’s
architectural and detailed designs that specify how
the software will be implemented
Suppliers of the
software product
• The developers are responsible for :
• implementing the designs by creating the
software products.

• The testers use the requirements as a basis for

creating test cases
Other Stakeholders
 Examples of other requirements stakeholders include:
 Legal or contract management
 Manufacturing or product release management
 Sales and marketing
 Upper management
 Government or regulator agencies
 Society at large
Importance of Identifying Stakeholders
 Identifyingthe stakeholders and getting them involved in the requirements engineering
process brings different perspectives to the table that can aid in a more complete set of
requirements early in the software development life cycle
 Identifying
and considering the needs of all of the different stakeholders can help prevent
software product requirements from being overlooked.
 Forexample, if a company is creating a payroll system and it does not consider charities as
one of its stakeholders, it might not include the requirements for the software to:
 Allow the payees to specify from one to three charitable deductions
 Withhold charitable deductions from payee’s checks each pay period
 Report current and year-to-date charitable deductions on payee’s pay slip
 Print a check to each charity for the accumulated amount deducted from payees
Challenges of Identifying Stakeholders
 Hard to identify, considering the need and involvement of all stakeholders
 What types of people will use the software product?
 What business activities are supported by the software product and who performs, is involved in, or manages those activities?
 Whose job will be impacted by the introduction of the new software product?
 Who will receive the reports, outputs, or other information from the software product?
 Who will pay for the software product?
 Who will select the software product or its supplier?
 Complexities and completeness is known to stakeholders
 Change is always resisted
 Preparation of checklist to identify stakeholders
 If the software product fails, who could be impacted?
 Who will be involved in developing, supporting, and maintaining the software product?
 Who established the laws, regulations, or standards governing the business activities supported by the software product?
 Who should be kept from using the software product or from using certain functions/data in the software?
 Who does this software product solve problems for?
 Who does this software product create problems for?
Stakeholder Analysis
 Identify who your stakeholders are.
 Direct/Indirect, Internal/External
 Work out their power, influence and interest.
 May have a long list of people and organizations that are affected by the work
 Some of these may have the power either to block or advance
 Some may be interested in what you are doing
 Some may not care.
 Map out stakeholders using the Power/Interest Grid, and classify them by their power over the
work and by their interest in the work.
 Develop a good understanding of the most important stakeholders.
Power/Interest Grid of Stakeholders
Power/Interest Grid of Stakeholders
 High power, interested people:
 these are the people you must fully engage and make the greatest efforts to satisfy.
 High power, less interested people:
 put enough work in with these people to keep them satisfied, but not so much that they become bored
with your message.
 Low power, interested people:
 keep these people adequately informed, and talk to them to ensure that no major issues are arising.
 These people can often be very helpful with the detail of your project.

 Low power, less interested people:

 again, monitor these people, but do not bore them with excessive communication.
When
 Requirements development activities includes:
 identifying, capturing, and agreeing upon the requirements
 The definition and integration of the business requirements, the user requirements, and
software product level requirements
 Majority of the activities occur early and elaboration can progress later.
 Requirements management activities involved in:
 Requesting changes to the base-lined requirements, performing impact analysis for the
requested changes, approving or disapproving those changes, and implementing the approved
changes.
 software product is validated against its requirements during the testing
How
 Software requirements engineering is a disciplined, process-
oriented approach to the definition, documentation, and
maintenance of software requirements throughout the
software development life cycle.
 Requirements development is an iterative process.
 One should not expect to go through the steps in a one-shot,
linear fashion
Requirements Engineering
Process
Requirements within the Software Development
Process (Step-Wise Quality Assurance)


39
What is the right system to build ?

40
The Requirements Engineering Process
RE activities and documents (Wiegers)
There needs to be an arrow from
 User requirements to System
requirements. (The system has to be
able to perform certain use cases.
The same use cases must be
supported by the software,
therefore become Software
requirements.)
Business rules (including standards
and regulations) are not only non-
functional, they also include
functional aspects (as shown by the
arrows in the diagram).

42
RE process model (suggested by Bray)
Again, this diagram shows
• RE activities (elicitation, analysis,
specification, HMI design)
• subsequent design activity (internal design)
• RE documents (elicitation notes,
requirements, specification, HMI specification)
Important point:
Distinction between
• Problem domain (described by requ. doc.)
• System (to be built) (described by spec.
doc.)
Note: One has to distinguish between current
(problematic) version of the problem domain,
and the projected future version which
includes the system to be built.
43
Typical Layered Approach (V-shaped)

Source: Hull, Jackson, Dick: Requirements Engineering, 2004

44
Notes on previous slide
 This looks like the waterfall process model, but this diagram describes a quite different situation.
 The layers correspond to step-wise refinement in terms of component decomposition.
 For instance, the transition from the first to the second layer is the typical RE process: one starts with
the information from elicitation (shown in the first layer), that is, the problematic domain model, and
one ends up with a proposal for a new system to be built (which is a component within the projected
new domain model).
 Importantnote: The process of identification of the system to be built and defining its relationship
with the new domain model (note that the environment of the system to be built may also be re-
organized within the new domain model) is a kind of “design process” that requires creativity.
 The
transitions to the lower layers in the diagram are similar processes (you may call them RE at a
more detailed level or design processes)

45
System modelling
 System modelling helps the analyst to understand the
functionality of the system and models are used to communicate
with customers
 Different models present the system from different perspectives
 External perspective showing the system’s context or environment
 Behavioural perspective showing the behaviour of the system
 Structural perspective showing the system or data architecture
Requirements and Modeling go together
 The system engineering sandwich!
 Why combining RE with modeling ?
 For analysis – models help to understand the problem domain
 For documentation – models can be used for describing
requirements (instead of solely using natural language)

Source: http://www.telelogic.com/download/paper/SystemsEngineeringSandwich.pdf
47
Different Levels of Details by Sandwich

Source: Hull, Jackson, Dick: Requirements Engineering, 2004

48
Benefits of Requirement Levels (Sandwich)
 Principle of step-wise refinement:
 Focus the attention on the big picture before addressing the details
 Reduce the number of changes by specifying at a lower level the
requirements that will not affect the requirements at a higher level
 Promote the division of work
 Thisdiagram [Lamsweerde] is another way to present this kind of
(spiral) process
49
Requirements Engineering as Set of
Activities
 Requirements engineering is a set of activities but not
necessarily a separate phase

Source: Donald C. Gause, Risk Focused Requirements Management, Tutorial at RE’09, September 2009
50
The Problem Domain and the
System/Software-to-be
What is a System
 Part of a reality that can be observed and interact with the environment
 Every system has a boundary
 Get inputs and send outputs
 Almost always composed of smaller sub-systems

 Examples
 Cars, weather, universe, Cardiovascular
 Operating Systems
 Database Servers
 Organizations

 Not Systems
 Numbers
 Letters
The Four Worlds
 Subject World: Things that need to be used in the information system e.g. Account, Transaction
in a bank account, Collision Alert
 Usage World: The environment where the future system will operate
 People (Manager, Clerk, Customer)
 Business Process (Withdraw money, Evasive Action (Plane))
 System World:
 What the system does within its operational environment?
 What is the information needed ?
 What functions should be performed? (System records log of use, System gives account Balance,
System monitors patient)
 Development World: (Process, Team, Schedule, Qualities (Non-Functional Requirements) e.g.
System to be delivered in 12 months, Team should not exceed 12 people .
System Boundary
 The part of the world that interacts with the system
 Every system has a subsystem
 The environment in itself is a system

 Choosing Boundaries
 Maximize modularity
 Telephone system – switches, phone lines, handsets, users, account
 Desktop Computer - ?
 Tips
 Exclude things that have no functional effect on the system
 Exclude things that influence the system but cannot be influenced or controlled by the system
 Include things that can be strongly influenced or controlled by the system
Problem Domain
 The problem domain is the context for requirements
 Part of the world within which the problem exists
 Needs to be understood for effective requirements engineering

 Domain model
 Set of properties assumed / believed to be true about the environment
 Properties relevant to the problem
 Problem domain requirements should hold in the proposed new version of the domain.

 Define the system requirements such that:

 If the system that is built satisfies the system requirements and the environment satisfies the properties
assumed for the environment, then the problem domain requirements will be satisfied.
 In simple words: The system will behave as required if the assumptions hold.

58
 Problem Domain and System-to-be


better: problem domain (as-is

Diagram also showing activities [Bray] Problem domain with system-to-be [Bray] and to-be)

A domain model should be

reusable (Michael Jackson, 1995)

Diagram showing existing and future situation [Lamsweerde]

59
Tackling the problem not the solution

• My Elevator is slow

•You have a throughput problem

not a speed problem !
 Tackling the problem not the solution

• My Elevator is slow
•Why is that a problem ?
• Well it’s a problem because
people complaint about the lines
•How better should it be?

As better as needed for

stopping complaints • Solution ????
Separating Problems from Solutions
 Need to check
 Solution correctly solves the
stated problem
 Problem statement corresponds to the real-world needs of the
stakeholders
The Machine and The World Shared Phenomena

 Applicationdomain – the world in which the machine

(system) will be introduced
 In particular – a part of the world in which the machine’s actions
will be observed and evaluated
 Machine domain – the set of phenomena the machine
(system) has access to (data, algorithms, devices, etc.)
 Shared phenomena – things observable to both domains
Problem Statement Description
 Domain Properties (Assumptions) – things in the application domain
that are true whether or not we ever build the proposed system
 Requirements – things in the application domain that we wish to be
made true by delivering the proposed system
 Many of which will involve phenomena the machine has no access to
 Specification– is a description of the behaviours that the program must
have in order to meet the requirements
 Can only be written in terms of shared phenomena!
Boundaries Can Be Moved: E.g., Elevator
Control System
 The nature of the problem to be solved can be changed
 Add sensors to detect when people are waiting/in the cabin
 Requirements analyst is responsible for the boundary!
System interface and software interface
 System
and software interface for a control system with
embedded software:
 Software interface: through input and output variables, for instance
measuredSpeed (is read by program) and doorState (is set by program)
 The system includes the software and I/O devices. Therefore the
interface of the system with the environment are the monitored and
controlled variables of the real world, for instance trainSpeed and
doorsClosed.
Generic architecture of a control system including embedded software [Lamsweerde] 66
Software objects representing real objects
 The software (model) normally contains objects that represent
objects in the system environment (e.g. the doorState variable
better: Problem domain requirements (if one considers the train to be the environment of the control system)

represents the state of the doors in the train)

 Whether they represent the situation in the environment
correctly, is another question (for the doorState variable, this
may depend on the correct functioning of the door state
sensing device).
67
[Lamsweerde]