Words of Wisdom

• Stop blaming and complaining. Raise

to the position when you have no one
Software Requirements Engineering
else to blame, but yourself.
• Namely that no bearer of burdens can bear the burden
of another. Al-Quran (53:38)
Week 2

Requirements Engineering? Processes

• Requirements Engineering • A process is an organized set of activities which
– A process in which “what is to be done” is elicited, modeled
transforms inputs to outputs
and communicated (Freeman) • Process descriptions encapsulate knowledge and allow
it to be reused
• “The descriptions of the services and constraints are • Examples of process descriptions
the requirements for the system” (Sommerville) – Instruction manual for a dishwasher
• “the process of finding out, analyzing, documenting – Cookery book
and checking these services and constraints is called – Procedures manual for a bank
– Quality manual for software development
Requirements Engineering.” (Sommerville)
• Process Model
– A simplified description of a process presented from a
particular perspective

1
 RE Process activities RE Process Activities
• Requirements Elicitation • Requirements Specification
– The process through which the customers, buyers, – The process of recording the requirements in one or more
forms, including natural language and formal, symbolic, or
or users of a software system discover, reveal, graphical representations
articulate, and understand their requirements
• Requirement Validation
• Requirement Analysis – The process of confirming with the customer or user of the
– The process of reasoning about the requirements software that the specified requirements are valid, correct,
that have been elicited and complete.
– Involves examining requirements for conflicts or • Requirement Management
inconsistencies, combining related requirements, – The process of managing all the activities carried out during
and identifying missing requirements RE

Type of Applications Problem-Solution

• Information systems and other application developed for use
within a company. Problem
– This category is the basis for the information system / information Space
technology industry
Identify the right Problem
• Commercial products needs Definition Solution
– Companies developing this type of software are often referred to as
independent software vendors, or ISVs. Space
• Embedded systems applications
Abstract
– Software that runs on computers embedded in other devices, machines, Define a high-level solution
Solution
or complex system
• System and Software System?
Detailed
Design the detailed solution Solution

2
 Problem-Solution Problem Domain
• The home of real users and other stakeholders, people whose
Problem Problem needs must be addressed in order for use to build the perfect
Space system
Needs • We are in the land of the alien user
• These users have business or technical problems

Tr a
Solution

ce
Features Space • It becomes our problem to understand their problems, in their

ab
culture and their language and to build systems that meet their

ilit
The
needs

y
Product
Software To Be • Since this territory can seem a little foggy. We need to make
Requirements Built sure that we are seeing all their issues in the problem space
clearly
Test • We elicit and understand those needs (stakeholder needs)
Procedures Design User
Docs

Solution Space
• We focus on defining a solution to the user’s problem • Next come specific requirements that we will need to impose
– this is the realm of computers, programming, operating systems, on the solution in order to provide features we promised
networks and processing nodes
• These more specific requirements are the software
• How we intend solve the problem?
– E.g., Web-enabled entry of sales orders
requirements
• The description of solution is done by features of the system to • If we build a system that conforms to those requirements, we
be built can be certain that the system we develop will deliver the
• A feature is a service that the system will provides to fulfill one features we promised. In turn, since the features address one
or more stakeholder needs or more stakeholder needs, we will have addressed those
• These features will be defined, debated, and prioritized needs directly in the solution.
• Ultimately we will have an established feature set and have
gained agreement with the customer

3
 The RUP Sets of Artifacts
• The artifacts of the Rational Unified Process fall into one of five
Phases categories, or information sets:
Process Workflows Inception Elaboration Construction Transition – Management set
Business Modeling – Requirements set
– Design set
Requirements
– Implementation set
Analysis & Design – Deployment set
Implementation • The requirements set groups all artifacts related to the
Test definition of the software system to be developed:
Deployment – The vision document
Supporting Workflows – Requirements in the form of stakeholders' needs, use-case model, and
supplementary specification
Configuration & Change Mgmt
– The business model, if it is required for an understanding of the business
Project Management processes supported by the system
Environment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1

Iterations

Modeling elements - Workflows Requirements Workflow

• Workflows
– A sequence of activities that produces a result of observable value
– RUP has nine core process workflow Develop Vision Elicit Stakeholder
• Six engineering Need
• Three supporting System Analyst Find Actors Structure the Requirements
and use cases Use Case Model Reviewer
• Business Modeling Manage Capture a
Decencies Common
– Documentation of business processes Vocabulary
– Assures a common understanding among stakeholders of what business
processes need to be supported in the organization Use-Case Specifier Detail a Use case
Review
• Requirements Requirements
– What the system should be or do?
– Allows the developers and customers to agree on that description User-Interface Designer User-Interface User-Interface
Modeling Prototyping

Architect Prioritize Use Cases

4
 Requirements workflow Requirements and Artifacts
• The purposes of the Requirements workflow are:
– To come to an agreement with the customer and the users on what the system
should do
– To give system developers a better understanding of the requirements of the
system
– To define the functionality of the system
– To provide a basis for planning the technical contents of iterations Vision
– To provide a basis for estimating cost and time to develop the system
– To define a user interface for the system
• To achieve these goals a Vision document, a Stakeholder Needs document, a Stakeholder
use-case model, and a Supplementary Specification document are Needs
Use-Case
developed that describes what the system will do - an effort that views Model Supplementary
customers and potential users as important sources of information (in Specification
addition to system requirements).
• Complementary to the above mentioned artifacts, the following artifacts are
developed:
– Glossary, Use-Case Storyboard, Boundary Class, User-Interface Prototype
Design Test
Model End-User
Model Documentation and
TRG Material

Workers
• System analyst • Use-case specifier
– The system analyst leads and coordinates requirements elicitation and use-case – is assigned a set of use cases and supplementary requirements, which
modeling by outlining the system's functionality and delimiting the system. he or she will detail and make consistent with other requirements
– Working with stakeholders of the project, understands what the system must do workflow artifacts.
and perhaps what it should not do and also identifies nonfunctional – The use-case specifier does not work in isolation but rather should
requirements. The system analyst can then develop a vision for the project. communicate regularly with other individual use-case specifiers as well
as with system analysts.

System Analyst
Use-Case
Specifier

Vision Stakeholder Use-Case Supplementary Requirements

Model Glossary Use Case Use-Case
Needs Specification Attributes
Package

5
 • Architect
• The user-interface designer – is responsible for identifying the
– works in parallel with the use-case specifier to design the architecturally significant use
cases and requirements and
system's user interface. In most cases, there is a synergistic contributing to their definition.
interaction between the two. – is involved primarily in earlier
iterations and works with the
system analyst and use-case
specifier Architect Software
• The requirements reviewer Architecture
– represents all the different kinds Document
of people you bring into verify
that the requirements are
correctly perceived and
User Interface interpreted by the development
Designer team.
Requirements
Reviewer
Boundary
Use-Case Class
Storyboard User Interface
Prototype

Q&A