Software

Requirements
Engineering
MISS . FATIMA YOUSAF
[Link]. IN COMPUTER SCIE NCE, BZU, MULTAN
Recap!

What did we cover yesterday?

Requirements Inception
•Often considered a complimentary activity to requirements elicitation
•Sometimes inception is considered a separate activity as well depending on the
RE process being followed
Problem Analysis
Goal: gain a better understanding of the problem
•Identify root cause
•Identify stakeholders and their needs (or problems)
•Identify solution boundary

•Results in Product Vision and Project Scope

Problem Analysis (Cont...)
Five steps for problem analysis (Leffingwell and Widrig )
1. Gain agreement on the problem definition
2. Understand the root causes – the problem behind the problem
3. Identify the stakeholders
4. Define the solution system vision and boundary
5. Identify the constraints to be imposed on the solution
Gain Agreement
Document the problem and seek agreement
•Ask stakeholders to write a problem statement in an agreed format
•Statement should include

• What the problem is

• Who is affected by it?
• What is the impact?
• Is there a proposed solution?
• What are key benefits?
Problem Analysis – Understand Root
Causes
•There is often a problem behind the problem
•Root cause analysis consists of finding underlying causes that may not be
immediately apparent
•Example: Our ecommerce site is not profitable

• Why is it not profitable?

• Poor site design?
• Bad pricing?
• Poor customer management after the sale?
• Some or all of the above?
Problem Analysis – Understand Root
Causes
•Root cause analysis can be used to understand root causes

• Determine what factors contribute to the problem (subproblems)

• Recursively determine what factors contribute to these problems
•Decompose until causes are understood (possible solution clear)
• Create problem statement for root cause problem identified as worth solving
(and with computer solution)
Problem Analysis – Stakeholders
•Stakeholders are individuals, groups, organizations who are actively involved in
the project, are affected by its outcome or are able to influence its outcome

•We must analyze:

•Major value or benefit that stakeholder will receive from product
•Likely attitude toward the product
•Major features and characteristics of interest
•Any known constraints that must be accommodated
Problem Analysis – Stakeholders
•How to identify Stakeholders?
•Who uses the system?
•Who is the customer?
•Who is affected by outputs?
•Who evaluates/approves system?
•Other external/internal users?
•Who maintains the system?
•Anyone who cares? (e.g., legal/regulatory, etc.)
Stakeholder Types
•Software engineers
•System end-users
•Managers of system end-users
•External regulators
•Domain experts
Actors vs. Stakeholders
•Actors interact with the system. They might be humans sitting at the computer
or other systems calling APIs or being called via APIs

•Stakeholders have some interest in the system. They include the users and many
others, e.g. company officers who invest in a system to improve their business
processes but never sign on the system themselves. We can also include
partners we will need to get the system built and installed, like the network and
production support staff
Actors
•Actors in a process are the people involved in the execution of that process
•Actors are normally identified by their roles rather than individually, e.g., project
manager, purchasing director, and system engineer
•Role-action diagrams are process models which show the actors associated with
different process activities
•They document the information needs of different people involved in the
process
Role Action Diagram Example
(For Prototyping)
ACTIONS
Establish Select
Understand outline Develop Evaluate
prototyping
problem requirements prototype prototype
system

Req. Engineer End-user

Domain expert Req. Engineer SW Engineer Req. Engineer Domain expert
End-user End-user Project Mgr SW Engineer Req. Engineer
SW Engineer
ROLES
Roles Explained
Roles Description
Domain Expert Responsible for proving information about the
application domain and the specific problem in
that domain, which is to be solved
System End-user Responsible for using the system after delivery
Requirements Engineer Responsible for eliciting and specifying the
system requirements
Software Engineer Responsible for developing the prototype
software system
Project Manager Responsible for planning and estimating the
prototyping project
Problem Analysis – Vision and Scope
•Product Vision: describes what the product is about and what it could
eventually become
• Aligns all stakeholders in a common direction
•Project Scope: identifies what portion of the ultimate long-term product vision the
current project will address
• Draws boundary between what is in and what is out

Product Vision

Project Scope Project Scope Project Scope

…..
for release 1.0 for release 1.1 for release n
Vision Statement
Vision Statement template (according to Moore)
• For [target customer]
• Who [statement of the need or opportunity]
• The [product name]
• Is [a product category]
• That [key benefit, compelling reason to buy or use]
• Unlike [primary competitive alternative, current system, or current business
process],
• Our product [statement of primary differentiation and advantages of new
product]
Example
For scientists who need to request containers of chemicals, the Chemical
Tracking System is an information system that will provide a single point of
access to the chemical stockroom and vendors. The system will store the
location of every chemical container within the company, the quantity of
material remaining in it and the complete history of each container's location
and usage. This system will save the company 25% on chemical costs in the first
year of use by allowing the company to fully exploit chemicals that are already
available within the company, dispose of fewer partially used or expired
containers and use a single standard chemical purchasing process. Unlike the
current manual ordering processes, our product will generate all reports
required to comply with government regulations that require the reporting of
chemical usage, storage, and disposal.
Defining Scope
•Definition of solution system boundaries
•New requirements during development are evaluated according to the scope
•New inscope requirements can be incorporated if they are of high priority
relative to the other requirements
•Outofscope requirements should be deferred to a following release or rejected
(a new contract may be signed)
Identifying Constraints
Sources of constraints include:
•Economics (e.g., costs, licensing issues)
•Politics (e.g., internal or external, interdepartmental issues)
•Technology (e.g., choice of technology/platform)
•Systems (e.g., existing system, compatibility issues)
•Environment (e.g., legal/environmental/security/standards)
•Schedule and resources (e.g., fixed schedule, team)