Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements:
● Functional and non-functional requirements
User World
Requirements
Software-Based System
NFRs
FRs
o A function of a system or component.
o Inputs, behavior, outputs.
o specifies what the system should do.
o List of feature-oriented product backlog.
o Example: Customer registration on the email.
30/10/2014
Chapter 1 Introduction
1
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements:
● Functional and non-functional requirements
User World
Requirements
Software-Based System
NFRs
FRs
●What makes a good FRs?
◌ Unambiguous ◌ Independent
◌ Testable
◌ Atomic (Tractable) [Nether created nor destroyed.]
◌ Clear
◌ Necessary
◌ Understandable ◌ Implementation free
◌ Feasible
30/10/2014
Chapter 1 Introduction
2
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Example for elaborating a good FRs.
• Sum of the first 100 odd numbers.
Procedures:
1. Write an English –like user stories.
2. Step 1: Re-write in your own script.
3. Step 2: Write sequence of instructions
4. Step 2.1: Discover the initialization, decision, incremental,
processing, repeating and terminating points.
1.1 As an calculator, I have to use <add> to compute the 1st 100
positive numbers, so that the sum is correctly printed.
2.1 Sum the 1st 100 odd numbers.
2.1.1 User initializes <First> odd number, (a=1)
2.1.2 User initializes <sum>, (sum=0).
30/10/2014
Chapter 1 Introduction
3
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Example for elaborating a good FRs.
• Sum of the first 100 odd numbers ….
Procedures …:
2.1.3 User enters <n> number as terminating input size, (<n> =
100).
2.1.4 Press the add button to take an action with <First> and
<sum> if <First> < <n>.
2.1.5 The system updates the <sum>, <sum> = <sum> + <First>.
2.1.6 The <First> increments by 2, <First> = <First> + 2.
2.1.7 The system repeats the steps 2.1.4 to 2.1.6.
2.1.8 The system prints the <sum>.
Home work:
• Apply the above steps to draw the flow chart diagram.
• Consider also sample test cases to check whether this diagram fulfilled
the good FRs.or not?
30/10/2014
Chapter 1 Introduction
4
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
User World
Requirements
Software-Based System
NFRs
FRs
●FRs are closely related to user stories.
●User stories use INVEST acronym.
◌ Independent ◌ Small
◌ Negotiable
◌ Testable
◌ Valuable
◌ Estimable
30/10/2014
Chapter 1 Introduction
5
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
User World
Requirements
Software-Based System
NFRs
FRs
o Usually, user stories should be short, simple descriptions of a solution
that your team has come up with.
o A user story usually focus on three areas:
o As a (who)
o I want to (what)
o So that (any)
30/10/2014
Chapter 1 Introduction
6
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
User World
Requirements
Software-Based System
NFRs
FRs
● Write some user stories: => example
 Develop an iPhone application that enables a complicated
password.
 As an admin, I am required to create a complicated password,
so that my account is secure.
.
30/10/2014
Chapter 1 Introduction
7
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
User World
Requirements
Software-Based System
NFRs
FRs
defines
Requirement
Engineering & Use
Cases
30/10/2014
Use Case
Basics
Chapter 1 Introduction
8
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
Requirements
User World
Software-Based System
NFRs
FRs
o FRs enable to capture the intended behavior of the system.
o This behavior may be expressed as services, tasks or functions the
system is required.
o Techniques for writing them: use cases, and requirements list with
shall statement.
30/10/2014
Chapter 1 Introduction
9
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
User World
Requirements
Software-Based System
NFRs
FRs
o FRs Main approaches:
o agile techniques that enable to foster the software development by
overriding the need to develop plan-oriented model for bridging
the requirement and the solution development.
o Example: List of features as High Level descriptions to form
the SCRUM which leads to contain the Low level
components..
30/10/2014
Chapter 1 Introduction
10
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements:
● Functional and non-functional requirements
User World
Requirements
Software-Based System
NFRs
FRs
o In agile:
o The Product backlog is maintained by the project
owner which contains every feature and requirement of
the product.
o Sprint backlog can be treated as the subset of product
backlog which contains features and requirements
related to that particular sprint only.
30/10/2014
Chapter 1 Introduction
11
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
Requirements
User World
Software-Based System
NFRs
FRs
o FRs Main approaches:
o SCRUM is a lightweight framework that helps people, teams and
organizations generate value through adaptive solutions for complex
problems (www.scrum.org/resources/what-is-scrum).(More examples in Chapter
two under Elicitation techniques)
30/10/2014
Chapter 1 Introduction
12
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
Requirements
User World
Software-Based System
NFRs
FRs
o FRs Main approaches:
o Behavior-driven development that enables to use the human
language as user stories to provide high level requirements through
creating features applicable especially for system and customer
testing. ( details in Chapter Five ).
30/10/2014
Chapter 1 Introduction
13
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
Requirements
User World
Software-Based System
NFRs
FRs
o captures the required properties or qualities of the
system.
o Describe the experience the user has while doing their
work.
o Do not alter the product’s functional. The functional
requirements remain the same no matter what
properties you attach to them.
o Example: Send an email in 2 secs
30/10/2014
Chapter 1 Introduction
14
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
Requirements
User World
Software-Based System
NFRs
FRs
o Often, how well some behavioral or structural
aspect of the system should be accomplished.
o Two categories:
o Observable at run time, e.g., performance, security,
reliability, availability, usability. Etc.
o Not Observable at runtime, e.g., extensibility,
portability, reusability, etc.
30/10/2014
Chapter 1 Introduction
15
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
Requirements
User World
Software-Based System
NFRs
FRs
o Constraint requirements have to be fulfilled.
o Other requirements that constrain the software project :
o Project constraints
o Project drivers ( stakeholders)
o Project issues (Plan, budget, risks, etc)
30/10/2014
Chapter 1 Introduction
16
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
Requirements
User World
Software-Based System
NFRs
FRs
30/10/2014
o Other requirements that constrain the software project …:
o Project constraints mean:
o define how the eventual system must fit into the
world and what rules must be followed in its
development.
Chapter 1 Introduction
17
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
Requirements
User World
Software-Based System
NFRs
FRs
o Other requirements that constrain the software project …:
o Project constraints come from
o
o
o
30/10/2014
Organizational constraints, e.g., deadlines, budget,
process standards, business rules;
Operational
constraints,
e.g.,
mandated
technologies, interfaces to hardware and other
software;
Legislative and Ethical constraints, e.g., safety,
privacy, health regulations/standards.
Chapter 1 Introduction
18
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
Requirements
User World
Software-Based System
NFRs
FRs
o Other requirements that constrain the software project …:
o Project drivers come from
o
30/10/2014
are the driving forces for the system:
o Purpose of the System;
o Client,
Customer
and
other
Stakeholders;
o Users of the System.
Chapter 1 Introduction
(non-user)
19
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
Requirements
User World
Software-Based System
NFRs
FRs
o Other requirements ….
o Project issues come from ( details in chapter six):
o
30/10/2014
define the ideas, concerns, and issues related to
the project:
o Open issues
o Installation and transition issues
o Risks
o Estimated cost
o Change Cases
o Ideas for solutions and off-the-shelf options 20
Chapter 1 Introduction
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
Requirements
User World
FRs
Software-Based System
NFRs
o Other requirements ….
o Project issues come from ( details in chapter six):
o
define the ideas, concerns, and issues related to the project::
o Burn-up and burn-down charts are used to keep track of the
progress of the project.
o
30/10/2014
Burn-up charts represent how much work has been completed in any
project whereas Burn-down chart represents the remaining work in a
project.
Chapter 1 Introduction
21
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
Requirements
User World
FRs
Software-Based System
NFRs
o Other requirements ….
• Velocity is a metric that is calculated by the addition of all efforts
estimates associated with user stories completed in an iteration.
.
• It predicts how much work Agile can complete in a sprint and how
much time will it require to complete a project.
30/10/2014
Chapter 1 Introduction
22
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
Requirements
User World
FRs
Software-Based System
NFRs
o Other requirements ….
o Agile testing is done parallel to the development activity whereas a
traditional waterfall model testing is done at the end of the
development.
o As done in parallel, agile testing is done on small features whereas,
in a waterfall model, testing is performed on the whole application.
30/10/2014
Chapter 1 Introduction
23
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
Requirements
User World
FRs
Software-Based System
NFRs
 Quality requirements:
o Complete: The specified requirements must be complete, there must be
nothing missing that is important for the development of the software.
o Consistent: If the software requirements are provided by more than one
customer. Then the software engineer must ensure that the
requirements provided by an individual must not contradict the
requirements provided by another customer.
30/10/2014
Chapter 1 Introduction
24
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
Requirements
User World
FRs
Software-Based System
NFRs
 Quality requirements:
o Unambiguous: Each specified requirement must be unambiguous i.e. it
must specify a single meaning.
o Functions: The requirement must specify what functions or
computations must the software perform and not how they must be
implemented.
30/10/2014
Chapter 1 Introduction
25
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
Requirements
User World
FRs
Software-Based System
NFRs
 Quality requirements:
 Concise: Each requirement must be specified only once and there
should not be duplication of any requirement statement.
 Minimum: The specified requirements must not carry unnecessary
details.
30/10/2014
Chapter 1 Introduction
26
Week 2 Lesson:
Introduction to Requirements Engineering
* Types of Requirements …:
● Functional and non-functional requirements
Requirements
User World
FRs
Software-Based System
NFRs
 Quality requirements:
o Understandable: The specified requirements must be understandable
by both customer and software developer.
o Achievable: The requirement must be technically feasible.
o Testable: It can be verified that the requirements are collected
completely.
30/10/2014
Chapter 1 Introduction
27
Week 2 Lesson:
Introduction to Requirements Engineering
• Phases of Requirement
• Requirements engineering is generally viewed as a process
containing two phases.
• 1st, it concentrates on the analysis and modeling of the
environment for the system-to-be, the organizational context,
the stakeholders, their objectives and their relationships.
• 2nd, it concerns with modeling the system together with its
environment.
30/10/2014
Chapter 1 Introduction
28
Week 2 Lesson:
Introduction to Requirements Engineering
• Requirement Elicitation (What?) (details in Chapter two).
•
is the process to find out the requirements for an intended
software system by communicating with client, end users,
system users and others who have a stake in the software
system development.
• There are various ways to discover requirements.
•
•
 Interviews
 Domain Analysis
 Surveys
 Brainstorming
 Questionnaires
 Prototyping
 Task analysis
 Observation
GORE focuses on the activities that precede the formulation of
software system requirements.
This GORE mainly covers approaches: goal elicitation,
goal
refinement and various types of
goal
analysis, and
the
assignment of responsibility for goals to agents.
30/10/2014
Chapter 1 Introduction
29
Week 2 Lesson:
Introduction to Requirements Engineering
• GORE approaches and concepts:
•
NFR Framework:
• concentrates on the modeling and analysis of nonfunctional
requirements.
•
•
The goal of the framework is to put non-functional requirements
foremost in developer’s mind.
The NFR framework also supports cataloguing design knowledge into
three main types of catalogues:
• NFR type catalogues include concepts about particular types of NFRs,
such as performance.
30/10/2014
•
Method catalogues encode knowledge that helps in softgoal
refinement and operationalization.
•
Correlation rule catalogues have the knowledge that helps in
detecting implicit interdependencies among softgoals.
Chapter 1 Introduction
30
Week 2 Lesson:
Introduction to Requirements Engineering
• GORE approaches and concepts …:
• Process (What?)
• A series of steps that when completed create an output of
some sort.
• Inputs are transformed into outputs,
• Process map (Why?)
• It is about collaboration and visual communication.
• Tools that supports analysts, project managers,
stakeholders.
• Levels of process mapping:
• Level 1: High-level description, what is happening.
• Level 2: Interaction description, what and who is
responsible, a bit more detail.
• Level 3: procedural description, what, who and how are
they transforming inputs.
30/10/2014
Chapter 1 Introduction
31
Week 2 Lesson:
Introduction to Requirements Engineering
• GORE approaches and concepts …:
o AS-IS and TO-BE
o The AS-IS state of a Process is the current state.
o It is how the process operates before you make any changes
or improvements.
o The TO-BE process, on the other hand, is the future state.
o Steps to understand and document the As-Is Process:
o Observation –the most straightforward approach. Simply observe the
process as it’s going on.
o Interviews –Personal interviews with employees working on the process.
o Questionnaires –Surveys on the process in question. More efficient than
holding interviews, but generally less informative.
o Project Teams –A special team composed of individuals who are either
employees working on the process itself, or process improvement
experts.
30/10/2014
Chapter 1 Introduction
32
Week 2 Lesson:
Introduction to Requirements Engineering
• GORE approaches and concepts …:
o AS-IS and TO-BE: Example scenarios on cyber security threats & emergency
alarm using activity diagram.
30/10/2014
Chapter 1 Introduction
33
Week 2 Lesson:
Introduction to Requirements Engineering
• GORE approaches and concepts …:
o AS-IS and TO-BE: Analyzing the As-Is Process and Finding Improvements
o Basic questions to be considered:
o Are deadlines frequently missed within the process?
o Are some of the process steps taking unusually long?
o Are some of the process steps a time or money sink? Why?
o What process step has the highest impact on output?
o Are there any ways to make it more efficient?
o Can you use technology to automate it?
o This step can be a bit hard if you’re not a full-fledged process
improvement consultant.
30/10/2014
Chapter 1 Introduction
34
Week 2 Lesson:
Introduction to Requirements Engineering
• GORE approaches and concepts …:
o AS-IS and TO-BE: Documenting and Implementing the To-Be Process
o The best practices for the change to get acceptance soon.
o Start Small – When a new process might seem to be a great
idea at a glance, it might turn out to be a disaster.
o To account for this, start the process on a small scale.
Once you are certain that the new process is empirically
better, you can scale it up & apply it company-wide.
o Enforce the Process – one can’t just go up to your
employees out of nowhere and say, “one will be doing things
completely differently from now on.” He/she needs to be
made aware of why he/she is making changes to the process
and how it’s going to affect their work.
30/10/2014
Chapter 1 Introduction
35
Week 2 Lesson:
Introduction to Requirements Engineering
• GORE approaches and concepts …:
o AS-IS and TO-BE: Documenting and Implementing the To-Be Process
o The best practices for the change to get acceptance soon.
o Benchmark the Metrics – One has to be 100% certain that
the new process is better than the old; otherwise, one is only
going to end up wasting time. Pick the right metrics to
benchmark post-implementation.
o Post-implementation: Implementing the to-be process state isn’t
exactly the end of your work. (Why ?)
o Soln: Appropriate assessment methods have to be employed
for ensuring the quality of system TO-BE.
o (See next slide.)
30/10/2014
Chapter 1 Introduction
36
Week 2 Lesson:
Introduction to Requirements Engineering
• GORE approaches and concepts …:
• Strategic dependencies for GORE such as to develop an agent
based framework through agile way agreement.
NFRSoftgoal
Assured [Attends
meeting]
Agent-1
Hardgoal-FR
Attends
meeting
Meeting
Initiator
Resource-1
Proposed
dates
Agreement
Agent-2
Meeting
Participant
Resource-2
Adapted from:
Eric Yu, "Towards Modeling and Reasoning Support for Early-Phase Requirements Engineering,"
Proc. Third IEEE Intol. Symposium on Requirements Engineering, pp 226-235, 1997
30/10/2014
Chapter 1 Introduction
37
Week 2 Lesson:
Introduction to Requirements Engineering
• All-in-one approach for Modeling RE and AS-IS-TO-BE
• The arrows show the data flow either uni- or bi-directional.
User World
Requirements
AS-IS
Agent
I-Star
Modeling
Software-Based System
Process
TO-BE
Goal
KAOS
Reqs Verification & Validation
Responsible
30/10/2014
Chapter 1 Introduction
38
Week 2 Lesson:
Introduction to Requirements Engineering
• Modeling RE and AS-IS-TO-BE …
• Modeling RE-Tools covers toolkits ( with StarUML)
30/10/2014
Chapter 1 Introduction
39
Week 2 Lesson:
Introduction to Requirements Engineering
• Modeling RE and AS-IS-TO-BE …
• Modeling RE-Tools covers toolkits ( with StarUML)
1.
2.
3.
30/10/2014
Chapter 1 Introduction
40
Week 2 Lesson:
Introduction to Requirements Engineering
• Modeling RE and AS-IS-TO-BE …
• Modeling RE-Tools covers toolkits ( with StarUML)
30/10/2014
Chapter 1 Introduction
41
Week 2 Lesson:
Introduction to Requirements Engineering
• Modeling RE and AS-IS-TO-BE …
• Modeling RE-Tools covers toolkits ( with StarUML) (these tool
supports employee core tasks to be covered in Chapter 4-6):
• Supports NFR Framework, i* Framework, KAOS, and Problem
Frames notations.
• For Product Specification
– Enterprise/domain/world, or business modeling, using OO,
GO/AO
– Software requirements modeling and specification, using
OO/GO/AO
• For Process Specification
– Functional process modeling, using IDEF/UML
– Non-functional process modeling, using NFR Framework/KAOS
30/10/2014
Chapter 1 Introduction
42
Week 2 Lesson:
Introduction to Requirements Engineering
• Modeling RE and AS-IS-TO-BE …
• Modeling RE-Tools covers toolkits ( with StarUML) (these tool
supports employee core tasks to be covered in Chapter 4-6):
• KAOS: Knowledge Acquisition in Automated Specification
• provides an illustration of the most formal application of the
goal-oriented approach to deriving requirements for computerbased systems.
•
30/10/2014
is to derive a description of a system’s behavior and an initial
analysis of its structure through acquiring and formalizing
functional and non-functional requirements (or goals) for a
composite system
Chapter 1 Introduction
43
Week 2 Lesson:
Introduction to Requirements Engineering
• Modeling RE and AS-IS-TO-BE …
• Modeling RE-Tools covers toolkits ( with StarUML) (these tool
supports employee core tasks to be covered in Chapter 4-6):
• Object model: UML classes, attributes and associations are derived
systematically from the goal specifications.
• Agent:
• The agent model captures responsibility links between agents
and goals together with monitoring/control links between agents
and object attributes.
• A goal assigned to some agent in the software-to-be is
operationalized into functional services, called operations, to be
performed by the agent.
30/10/2014
Chapter 1 Introduction
44
Week 2 Lesson:
Introduction to Requirements Engineering
• Modeling RE and AS-IS-TO-BE …
• Modeling RE-Tools covers toolkits ( with StarUML) (these tool
supports employee core tasks to be covered in Chapter 4-6):
• Goal: A goal is a stakeholder need to be achieved.
•
A goal may be either a hardgoal (e.g. an object dispatched) or
a softgoal (e.g. safety and security) depending on whether it
has clear-cut achievement criteria.
• Resource: the constraints that responsible for processing of the
agents interaction.
30/10/2014
Chapter 1 Introduction
45
Week 2 Lesson:
Introduction to Requirements Engineering
• Modeling RE and AS-IS-TO-BE …
• Modeling RE-Tools covers toolkits ( with StarUML) (these tool
supports employee core tasks to be covered in Chapter 4-6):
• NRFSoftGoal: A softgoal may be refined using an And/Ordecomposition (denoted by a single/double arc) to more
specific sub-goals.
• SIG: Softgoal Interdependency Graph (SIG)
• PIG: Problem Interdependency Graph (PIG)
30/10/2014
Chapter 1 Introduction
46
Week 2 Lesson:
Introduction to Requirements Engineering
•
Softgoal Interdependency Graph (SIG) and Problem Interdependency Graph
(PIG)
1. Concepts
- Softgoal Interdependency Graph
- Problem Interdependency Graph
2. Relationships
- Decomposition Relationships
30/10/2014
- Contribution Relationships
Chapter 1 Introduction
47
Week 2 Lesson:
Introduction to Requirements Engineering
• Modeling RE and AS-IS-TO-BE: RE-Tools symbols and Scientific
notations.
30/10/2014
Chapter 1 Introduction
48
Week 2 Lesson:
Introduction to Requirements Engineering
• Modeling ….: Core RE-Tools symbols and Scientific notations.
30/10/2014
Chapter 1 Introduction
49
Week 2 Lesson:
Introduction to Requirements Engineering
• Modeling RE …: Core RE-Tools symbols and Scientific notations.
30/10/2014
Chapter 1 Introduction
50
Week 2 Lesson:
Introduction to Requirements Engineering
• Modeling RE …:Core RE-Tools symbols and
Scientific Notations.
30/10/2014
Chapter 1 Introduction
51