SlideShare une entreprise Scribd logo
1  sur  153
Télécharger pour lire hors ligne
SOFTWARE REQUIREMENT ENGINEERING
Prepared By:
Ahmed Alageed
1
4- RESPONSIBILITIES AND ROLES
LEARNING TARGET
 What basic roles are there in Requirements
Engineering?
 What is a stakeholder?
 What are the tasks of Requirements
Engineering?
 What is the task of a Professional for
Requirements Engineering?
 What characterizes a Professional for
Requirements Engineering?
2
4.1 BASIC ROLES
 Client (= customer)
 a customer is an individual or organization
who derives either direct or indirect benefit
from a product
 The client formulates his needs ( Business
Requirement , User Requirement)
 Contractor (= supplier)
 The contractor delivers solutions (RA)
3
STAKEHOLDER
 A stakeholder is a person or a role that has
an interest
 Stakeholders can be either natural persons,
legal entities or abstract persons
 Stakeholders often have conflicts of interest
among each other
 Important: Identification of all stakeholders in
order to take adequate consideration of all
perspectives
4
THE CUSTOMER-DEVELOPMENT PARTNERSHIP (
CUSTOMER RIGHTS )
 To Expect Analysts to Speak Your Language
 To Have Analysts Learn About Your Business
and Objectives
 To Expect Analysts to Write a Software
Requirements Specification
 To Receive Explanations of Requirements
Work Products
 To Expect Analysts and Developers to Treat
You with Respect
5
THE CUSTOMER-DEVELOPMENT PARTNERSHIP (
CUSTOMER RIGHTS )
 To Describe Characteristics That Make the
Product Easy to Use
 To Be Given Opportunities to Adjust
Requirements to Permit Reuse
 To Receive Good-Faith Estimates of the
Costs of Changes
 To Receive a System That Meets Your
Functional and Quality Needs
6
THE CUSTOMER-DEVELOPMENT PARTNERSHIP (
CUSTOMER RESPONSIBILITIES )
 To Educate Analysts and Developers About
Your Business
 To Spend the Time to Provide and Clarify
Requirements
 To Be Specific and Precise About
Requirements
 To Make Timely Decisions
 To Respect a Developer's Assessment of
Cost and Feasibility
7
THE CUSTOMER-DEVELOPMENT PARTNERSHIP (
CUSTOMER RESPONSIBILITIES )
 To Set Requirement Priorities
 To Review Requirements Documents and
Evaluate Prototypes
 To Promptly Communicate Changes to the
Requirements
 To Follow the Development Organization's
Change Process
 To Respect the Requirements Engineering
Processes the Analysts Use
8
RA ROLES
 Work collaboratively with customers, users,
and system architects and designers to
identify the real requirements for a planned
system or software development effort to
define the problem that needs to be solved.
 Identifying the stated needs of customers and
users.
 Studying the business objectives
9
RA ROLES
 Collaborating with customers and users in a joint
or cooperative environment to analyze the stated
requirements, evolve better requirements, and
prioritize them
 Involving system architects in requirements
development.
 Utilizing an industry-strength automated
requirements tool to support this work.
10
RA ROLES
 Work effectively with customers and users to
manage new and changed requirements so
that the project stays under control. Install a
mechanism to control changes.
 Be alert to new technologies that may help.
 Facilitate the project’s reuse of artifacts and
achieving repeatability.
11
RA ROLES
 Assist the project and its customers in
envisioning a growth path from the first
release or version of a product through a set
of staged releases to the ultimate system or
product.
 Advise the project (and customer) of
methods, techniques, and automated tools
that are available to best support
requirements-related project work and
activities. 12
RA ROLES
 Use metrics to measure, track, and control
requirements-related project work activities
and results.
 Be able to facilitate discussions and to
mediate conflicts.
 Study the domain of the area in which the
system or software is being used.
13
KNOWLEDGE OF A PROFESSIONAL FOR
REQUIREMENTS ENGINEERING:
 Skill of moderation
 Self-confident manner
 Ability to convince
 Language skills
 Ability to communicate
 Precision
 Analytical, clear thinking
 Ability to act in a structured way
 Methodological competence
 Stress resistance
14
4.2 TASKS OF REQUIREMENTS ENGINEERING
 Analysis of business processes
 Identification and analysis of requirements
 Quality assurance of requirements and
specifications
 Creation of the requirements specification
 Risk analysis
The Professional for Requirements Engineering identifies
wishes and aims.
15
ANALYSIS OF BUSINESS PROCESSES
 Analyze the business context Include the
following tasks:
 Analyze the customer organization’s
business enterprise to understand the:
 Business model.
 Organizational structure and relationships.
 Technology currently being used.
 Relevant planned improvements.
16
ANALYSIS OF BUSINESS PROCESSES
 Analyze the competitor organizations that
produce competing systems to:
 Identify, profile, analyze, and understand the
competitors.
 See how the planned system [upgrade] will
improve the customer organization’s business
enterprise and help it compete.
17
ANALYSIS OF BUSINESS PROCESSES
 Analyze current and potential/planned
marketplaces
 Analyze critical technologies
 Analyze current and intended future user
communities (to understand their needs and
desires and determine how the system might
improve their tasks and workflows)
18
ANALYSIS OF BUSINESS PROCESSES
 Analyze the stakeholders to:
 Identify different stakeholder
persons, roles, organizations, and systems.
 Profile them including categorizing them into
well-defined and well understood groups.
 Understand their
needs, desires, responsibilities, and tasks.
19
ANALYSIS OF BUSINESS PROCESSES
 Develop a business case to determine
whether the system [enhancement] should
be developed by
 Determining is costs and benefits
 Comparing its merits relative to those of
competing systems.
20
ANALYSIS OF BUSINESS PROCESSES
 VISIONING During this task, the main
RE team collaborates with key
stakeholders to produce a vision of the
new system
Define the system’s mission.
Determine the business problems and
opportunities to be solved by the system.
Determine the most important stakeholder
needs to be fulfilled by the system.
21
VISIONING
Determine the most important business,
functional, and quality goals of the system.
Determine any major business, technical,
and legal/regulatory constraints on the
system.
 Use this information to build a consensus
among key system stakeholders regarding
the vision of the system to lay a foundation
on which the system requirements can be
engineered.
22
IDENTIFICATION AND ANALYSIS OF
REQUIREMENTS
 Requirement Identification : During this task,
the RE teams identify potential requirements
include:
 Identify sources of requirements (e.g.,
stakeholders, documents, legacy systems,
problem reports, etc).
 Elicit needs, goals, desires, and requirements
from a representative sample of all major
stakeholder types
23
REQUIREMENT IDENTIFICATION
 Gather potential requirements from existing
documents describing legacy or competing
systems, problem reports, marketing surveys,
and other sources.
 Invent new requirements so that the system will
be truly better than the legacysystems it will
replace and therefore worth building. Invention is
a critically important, though underutilized,
technique for identifying requirements, and is
often the difference between a highly successful
system and a marginally successful system.
24
REQUIREMENT IDENTIFICATION
 Transform stakeholder desires, expectations,
and needs into informal, textual, potential
requirements.
25
REQUIREMENTS IDENTIFICATION
 During this task, the RE teams identify
potential requirements. This task typically
includes the following subtasks:
 Identify sources of requirements (e.g.,
takeholders, documents, legacy
systems,problem reports, etc).
 Elicit needs, goals, desires, and requirements
from a representative sample of all major
stakeholder types
26
REQUIREMENTS IDENTIFICATION
 Gather potential requirements from existing
documents describing legacy or competing
systems, problem reports, marketing surveys,
and other sources.
 Invent new requirements so that the system will
be truly better than the legacy systems it will
replace and therefore worth building
 Transform stakeholder desires, expectations,
and needs into informal, textual, potential
requirements.
27
REQUIREMENTS REUSE
 During this task, the RE teams reuse all or
part of preexisting requirements work
products. This task typically includes the
following subtasks:
 Identify any potentially relevant reusable
requirements work products (e.g., individual
requirements, requirements templates,
requirements diagrams, requirements models,
and requirements specifications
complete work products + parts of work
products 28
REQUIREMENTS REUSE
 Evaluate the identified reusable requirements
work products for relevancy to the current
endeavor.
 Tailor the relevant identified reusable
requirements work products to meet the needs of
the current endeavor.
 Reuse the tailored reusable work products by
incorporating them into the current endeavor’s
requirements work products.
29
REQUIREMENTS ANALYSIS
 During this task, the RE teams analyze the
identified and reused requirements. Include:
 Study, categorize, decompose and organize,
model, quantify, refine, prioritize, justify, and
trace each requirement to its source(s).
 Transform informal textual requirements into
semiformal or formal requirements (if formal
methods are used).
30
REQUIREMENTS ANALYSIS
 Negotiate the prioritization of requirements with
the requirements stakeholders, and use the
negotiated prioritization to help schedule the
implementation of the requirements. Note that
this subtask is often performed concurrently with
the requirements validation task.
 Verify any related assumptions.
31
REQUIREMENTS ANALYSIS
 Transform potential raw requirements and
related information into real requirements that
have the necessary quality characteristics such
as clarity (i.e.,lack of
ambiguity), completeness, consistency, correctne
ss, feasibility
(e.g.,technical, financial, schedule, etc.), verifiabil
ity, and understandability.
 Ensure that the requirements are sufficiently well
understood that they can be properly specified.
32
REQUIREMENTS PROTOTYPING (OPTIONAL)
 During this task, the RE teams generate
requirements engineering prototypes. Include
:
 Produce one or more requirements prototypes
(e.g., paper or wireframe prototypes of user
interfaces or executable models).
 Evaluate these prototypes. This may involve
analysis of static prototypes or execution and
evaluation of dynamic prototypes.
33
REQUIREMENTS PROTOTYPING (OPTIONAL)
 Use these prototypes to:
 Help identify new requirements such as
functional, data, and quality requirements
regarding user interfaces.
 Better understand existing requirements.
 Identify defects in the existing requirements that
drove the development of these prototypes.
 Support the analysis of these requirements.
34
REQUIREMENT ANALYSIS PROCEDURE
1. Analysis of the needs
2. Description of the solution
3. Cost estimate and prioritization
35
7.2 METHODS AND TECHNIQUES
 Different aspects of a system are
represented through different views
 Models are developed through suitable
methods of analysis
 Differentiation between types of models
 Requirements models
 Solution models
36
DIFFERENT MODELS (STRUCTURED)
 Context model
 Functional decomposition
 Data flow model
 State transition model
 Petri Net
 Entity Relationship Model
37
CONTEXT MODEL
 Is a diagram that represents the actors
outside a system that could interact with that
system
 This diagram is the highest level view of a
system.
 SCDs show a system, often software-based,
as a whole and its inputs and outputs from/to
external factors
38
39
FUNCTIONAL DECOMPOSITION
 A Functional Decomposition Diagram
enables you to view your system functions in
an hierarchical structure
40
41
DATA FLOW MODEL
 DFDs show the flow of data from external
entities into the system, showed how the
data moved from one process to another, as
well as its logical storage
42
43
STATE TRANSITION MODEL
 describe the behavior of systems
 State diagrams require that the system
described is composed of a finite number of
state
44
45
PETRI NET
 Like the activity diagram
46
ENTITY RELATIONSHIP MODEL
 is an abstract and conceptual representation
of data. Entity-relationship modeling is a
database modeling method,
 used to produce a type of conceptual
schema or semantic data model of a system,
often a rational database, and its
requirements in a top-down fashion
47
48
7.3 OBJECT-ORIENTED ANALYSIS
 UML (Unified Modeling Language)
 UML provides diagrams for different views of
the system
 Use case diagrams, class diagrams, activity
diagrams, state diagrams, object diagrams,
sequence diagram, component diagrams,
package diagrams, etc.
49
USE-CASE DIAGRAM
 Use-Case diagrams are probably the
simplest diagramming notation within the
UML
 Use-Case diagrams model the operations of
the system as perceived by an outside user
 i.e. They model ‘what’ the system does rather
than ‘how’ it does it !
50
USE-CASE DIAGRAM
 The two primary elements of UC diagrams are Actors
and Use-Cases
 Actors - (shown as stick-men on diagrams)
 Model the outside users of the system
 Actors are not always humans, can be other
computer systems; external devices etc.
 A single user may actually be a different actor at the
same time
 Many users may be the same actor at the same time
 It is actors that initiate a particular use-case
51
USE-CASE DIAGRAM
 Use-Cases - (shown as an ellipse on diagrams)
 A use-case is a unit of an externally visible
operation (i.e. a single use of the system)
 Each use-case is orthogonal within the model
(i.e. each use-case can be performed
independently and in any order)
 Each use-case can connect to one or more
actors by a solid line, this indicates an
association between an actor and that particular
use of the system
52
USE-CASE DIAGRAM EXAMPLE
53
Open
Account
Close
Account
Credit
Account
Debit
Account
Print
Statemen
t
Accounts
manager
Teller
ATM
Bank
System
REFINING USE-CASE DIAGRAMS
 Once an initial use-cases have been documented
they can be refined
 The refining of a Use-Case diagram can help
simplify and remove unnecessary redundancy
 There are three main ways in which refinement can
be performed (usually aided by reading
descriptions, see later)
 Identification of shared sequences of operations
 Identification of alternative actions within single use-
cases
 Identification of common behavior between use-cases
54
USING <<INCLUDE>> ASSOCIATIONS
 This type of association allows a shared
sequence of operations to be included in several
use-cases
 Simplifies a use-case diagram by factoring out
common operations
 When a use-case is included within another
use-case the operations are always
incorporated
 The operations from the included use-case are
NOT interleaved, they exist as a single block
 Including a use-case is similar to calling a sub- 55
<<INCLUDE>> EXAMPLE
56
Open
Account
Close
Account
Credit
Account
Debit
Account
Print
Statemen
t
Accounts
manager
Teller
ATM
Bank
System
Check
Account
Balance
USING <<EXTEND>> ASSOCIATIONS
 This type of association allows a sequence of
operations to be conditionally included in a use-
case
 Improves the model by identifying less common
alternatives to operations normally performed
 Extensions are typically attached to an
extension-point within the use-case which is
being extended
 If a specific condition is true at the extension
point then the extending use-cases operations
are included, otherwise they are not
 Similar to an ‘if-then’ construct within a program57
<<EXTEND>> EXAMPLE
58
Open
Account
Close
Account
Credit
Account
Debit
Account
Print
Statemen
t
Accounts
manager
Teller
ATM
Bank
System
Check
Account
Balance
Reject
Request
USING GENERALIZATION/SPECIALIZATION
 This type of association allows common behavior
to be extracted into generalized use-cases
 The common behavior is then inherited by
specialized use-cases
 Additional steps in the specialized use-cases can
be interleaved with those inherited from the
generalized use-case
 A specialized use-case inherits associations from
its generalized use-case, and can be substituted
for its generalized use-case
GENERALIZATION/SPECIALIZATION EXAMPLE
Open
Account
Close
Account
Credit
Account
Debit
Account
Print
Statemen
t
Accounts
manager
Teller
ATM
Bank
System
Check
Account
Balance
Transfer
Funds
Reject
Request
INTERNALS OF USE-CASES
 Use-Case diagrams do not show internal
workings of each use-case
 These can be documented using other UML
diagrams or natural language
 Tend to use natural language during analysis and
UML diagrams later in the lifecycle
 Natural language descriptions should be well-
formed and consist of an agreed upon format
within the s/w company
A FORMAT DEFINITION FOR TEXTUAL USE-
CASE DESCRIPTIONS
List all pre-conditions
X-reference name of any generalized use-case
List main sequence of operations (numbered)
Show included use-cases as single step, X-ref the name
List alternatives
X-ref the sequence number of extension point
Specify condition for extension to be utilized
X-reference the sequence number of re-entrance point
EXAMPLE DOCUMENTATION OF A USE-
CASE
Use-case : debit account
Inherits from : Transfer Funds
pre-condition: account number exists
1. Read amount to be debited
2. Perform check (Check Account
Balance)
3. Deduct amount to be debited
4. Report success code
USE-CASE SUMMARY
 Accurate requirements are very important to the
success of analysis and design
 Use-Case diagrams can be used to model
requirements as seen from an external, or users’
point of view
 Actors & Use-Cases are the two primary elements
of a Use-Case diagram
 Refinement of a Use-Case diagram helps remove
redundancy
 Internals of each use-case can be defined using
other UML diagrams and/or natural language
ACTIVITY DIAGRAM
 Activity diagram is used to display the
sequence of activities
 Activity Diagrams show the workflow from a
start point to the finish point detailing the
many decision paths that exist in the
progression of events contained in the
activity
 They may be used to detail situations where
parallel processing may occur in the
execution of some activities
 Activity Diagrams are useful for Business
Modeling where they are used for detailing
the processes involved in business activities65
66
ACTIVITY NODE
 An activity is the specification of a
parameterized sequence of behavior
 An activity is shown as a round-cornered
rectangle enclosing all the actions, control
flows and other elements that make up the
activity
67
ACTION NODE
 An action represents a single step within an
activity
 Actions are denoted by round-cornered
rectangles.
68
ACTION CONSTRAINTS
 Constraints can be
attached to an
action
 This sample shows
an action with local
pre and post-
conditions.
69
CONTROL FLOW
 A control flow shows the flow of control from
one action to the next one
 Its notation is a line with an arrowhead.
70
INITIAL NODE
 An initial or start node is depicted by a large
black spot, as depicted below
71
ACTIVITY FINAL NODE
 There are two types of final node
 activity final
 flow final nodes
 The activity final node is depicted as a circle
with a dot inside
72
FLOW FINAL NODE
 The flow final node is depicted as a circle
with a cross inside
 The difference between the two node types
is that the flow final node denotes the end of
a single control flow
 The activity final node denotes the end of all
control flows within the activity
73
SAMPLES OF ACTIVITY AND FLOW FINAL NODES
 A flow dies without ending the whole activity
 A flow final node terminates its own path not
the whole activity
 It is shown as a circle with an X through it
74
BASIC CONTROL FLOWS
 Sequential Control Flow
 Branch Control Flow
 Iteration Control Flow
75
SEQUENTIAL CONTROL FLOW
 A Sequence of Activities Node
 Unconditional Flow
76
BRANCH CONTROL FLOW
 Decision nodes and merge nodes have the
same notation - using a diamond shape
 They can both be named
 The control flows coming away from a
decision node will have guard conditions
which will allow control to flow if the guard
condition is met
77
DECISION NODE
 Decisions are used when you want to
execute a different sequence of actions
depending on a condition
 Decisions are drawn as diamond-shaped
nodes with one incoming edge and multiple
outgoing edges
 Each branched edge contains a guard
condition written in brackets
 Guard conditions determine which edge is
taken after a decision node
78
79
MERGE NODE
 The branched flows join together at a merge
node, which marks the end of the conditional
behavior started at the decision node
 Merges are also shown with diamond-
shaped nodes, but they have multiple
incoming edges and one outgoing edge
80
USING MERGE NODE IN UML2
 In UML 2.0, it's better to be as clear as
possible and to show merge nodes
81
EXCLUSIVE GUARDS NEEDED
82
ITERATION CONTROL FLOW
 A loop is a sequence of activity nodes which
is specified once but which may be carried
out several times in succession
83
CONCURRENT ACTIVITIES
 Forks and Joins have the same notation –
using either a horizontal or vertical bar
 They indicate the start and end of concurrent
threads of control
84
CONCURRENT ACTIVITY
 When actions occur in parallel, it doesn't
necessarily mean they will finish at the same
time
 In fact, one task will most likely finish before
the other
 However, the join prevents the flow from
continuing past the join until all incoming
flows are complete
85
86
CLASS DIAGRAM
87
STATE DIAGRAM
88
7.4 COST ESTIMATES
 Cost estimates connect Requirements
Engineering with the project management
Types of estimate
 Costs
 Time
 Requirements
 Quality
 Cost estimates help to recognize the cost for
change
89
ESTIMATION PROCEDURE
 Conclusions by analogy
 Algorithmic procedure
 Function point procedure
 bottom-up Approach
 Estimation procedures are always based on
historical data and framework conditions
90
7.5 PRIORITIZATION
 Why prioritization?
 Prioritization is a way to deal with competing
demands for limited resources
 A project manager must balance the desired
project scope against the constraints of
schedule, budget, staff, and quality goals.
One way to accomplish this is to drop—or to
defer to a later release—low-priority
91
GAMES PEOPLE PLAY WITH PRIORITIES
 Customers and developers both should
provide input to requirements prioritization
 customers will establish perhaps 85 percent
of the requirements as high priority, 10
percent as medium, and 5 percent as low.
 High priority mean high risk.
92
ENCOURAGE CUSTOMER TO IDENTIFY LOW
PRIORITY REQUIREMENT
 ask questions such as the following:
 Is there some other way to satisfy the need that
this requirement addresses?
 What would the consequence be of omitting or
deferring this requirement?
 What would the impact be on the project's
business objectives if this requirement weren't
implemented immediately?
 Why would a user be unhappy if this requirement
were deferred to a later release?
93
A PRIORITIZATION SCALE
 common prioritization approach groups
requirements into three categories
 One way to assess priority is to consider the
two dimensions of importance and urgency
 High priority requirements are both important
(the user needs the capability) and urgent (the
user needs it in the next release). Contractual or
legal obligations might dictate that the
requirement must be included, or there might be
compelling business reasons to implement it
promptly.
94
A PRIORITIZATION SCALE
 Medium priority requirements are important (the
user needs the capability) but not urgent (they
can wait for a later release).
 Low priority requirements are not important (the
user can live without the capability if necessary)
and not urgent (the user can wait, perhaps
forever).
 Requirements in the fourth quadrant appear to
be urgent but they really aren't important. Don't
waste your time working on these. They don't
add sufficient value to the product.
95
Important Not Important
Urgent High
Priority
Low Priority
Not
Urgent
Medium
Priority
Don't do these!
96
REQUIREMENTS PRIORITIZATION BASED
ON IMPORTANCE AND URGENCY
PRIORITIZATION BASED ON VALUE, COST, AND
RISK
 The typical participants in the prioritization
process include:
 The project manager, who leads the process,
arbitrates conflicts, and adjusts input from the
other participants if necessary
 Customer representatives, such as product
champions or marketing staff, who supply the
benefit and penalty ratings
 Development representatives, such as team
technical leads, who provide the cost and risk
ratings
97
STEPS OF THE PRIORITIZATION MODEL
 Step 1:
 List in the spreadsheet all the features, use
cases, or requirements that you want to
prioritize; All the items must be at the same level
of abstraction—don't mix functional requirements
with product features.
 If certain features are logically linked (for
example, you'd implement feature B only if
feature A were included),
 list only the driving feature in the analysis.
 If you have more items than that, group related
features together to create a manageable initial
list. 98
STEPS OF THE PRIORITIZATION MODEL
 Have your customer representatives
estimate the relative benefit that each feature
would provide to the customer or to the
business on a scale of 1 to 9. A rating of 1
indicates that no one would find it useful and
9 means it would be extremely valuable.
These benefit ratings indicate alignment of
the features with the product's business
requirements.
99
 Estimate the relative penalty that the
customer or business would suffer if the
feature were not included. Again, use a scale
of 1 to 9. A rating of 1 means that no one will
be upset if it's excluded; 9 indicates a serious
downside. When assigning penalty ratings,
consider how unhappy the customers will be
if a specific capability isn't included. Ask
yourselves questions such as the following:
100
STEPS OF THE PRIORITIZATION MODEL
ESTIMATE THE RELATIVE PENALTY
 Would your product suffer in comparison with other
products that do contain that capability?
 Would there be any legal or contractual
consequences?
 Would you be violating some government or industry
standard?
 Would users be unable to perform some necessary
or expected functions?
 Would it be a lot harder to add that capability later as
an enhancement?
 Would problems arise because marketing has
promised a feature to satisfy some potential
101
STEPS OF THE PRIORITIZATION MODEL
 By default, benefit and penalty are weighted
equally. As a refinement, you can change the
relative weights for these two factors
102
STEPS OF THE PRIORITIZATION MODEL
 Have developers estimate the relative cost of
implementing each feature, again on a scale
of 1 (quick and easy) to 9 (time consuming
and expensive). Developers estimate the
cost ratings based on the feature's
complexity, the extent of user interface work
required, the potential ability to reuse existing
code, the amount of testing and
documentation that will be needed, and so
forth.
103
STEPS OF THE PRIORITIZATION MODEL
 Similarly, have developers rate the relative
degree of technical or other risks associated
with each feature on a scale of 1 to 9.
Technical risk is the probability of not getting
the feature right on the first try. A rating of 1
means that you can program it in your sleep.
A 9 indicates serious concerns about
feasibility, the lack of staff with the necessary
expertise, or the use of unproven or
unfamiliar tools and technologies.
104
STEPS OF THE PRIORITIZATION MODEL
 Once you've entered all the estimates into
the spreadsheet, it will calculate a priority
value for each feature using the following
formula:
 priority = value %
(cost % * cost weight) + (risk % * risk weight)
105
SPECIFICATION OF REQUIREMENTS
 In the specification, requirements are
specified in a structured way and are
modeled separately.
 The specification serves to track and
manage requirements.
106
CREATION OF THE REQUIREMENTS
SPECIFICATION
 During this task, the RE teams generate and
publish analyzed and/or validated
requirements in paper or electronic
requirements specification documents.
Include:
 System, subsystem, software, and hardware
requirements specifications containing the
individual requirements and associated ancillary
information.
107
CREATION OF THE REQUIREMENTS
SPECIFICATION
 Operational concept documents (OCDs)
containing use cases, misuse or abuse cases,
and usage scenarios.
 Glossary and Domain Object Model to properly
define the meaning of the terms used in the
requirements
108
CREATION OF THE REQUIREMENTS
SPECIFICATION
 Distribute the requirements specifications to their
audiences or make access available to them.
 Iterate the requirements specifications as a
result of informal feedback. Note that more
formal feedback will come as part of the
requirements verification subtask of quality
engineering.
109
STANDARD CONTENTS OF A REQUIREMENTS
DOCUMENT
 Introduction
 Secrecy clause
 Regulations
 Standards
 Stakeholder
 Purpose of the product
 Description of the system
110
STANDARD CONTENTS OF A REQUIREMENTS
DOCUMENT
 Functional requirements
 Non-functional requirements
 Assumptions
 Dependencies
 Risks
 Safety requirements
 Software Quality Attributes
 Acceptance
111
LEVEL OF SPECIFICATION
 Requirements specifications
 Are also called performance specifications
 The creation should be the customer's task
 Solution specifications
 Are also called functional specifications
 The basis for the further system development
112
SPECIFICATION PROCEDURE
 Specification as an activity for formalizing the
results of the requirements analysis
 Different degrees of formalization
 Non-formal
 Semi-formal
 Formal
113
REQUIREMENTS MANAGEMENT
 During this task, the RE teams manage all
requirements, regardless of their status.
 Record and store the requirements and their
attributes (i.e., metadata about the requirements)
in an appropriate repository, database, or
requirements management tool.
 Control access (e.g., create, read, update,
delete) to the requirements (e.g., based on
metadata such as authorization to
create/read/update/delete requirements by role,
requirement state, requirement ownership,
requirement responsibility, date of last change to
the requirement, etc.).
114
REQUIREMENTS MANAGEMENT
 Negotiate with the stakeholders to eliminate any
inconsistencies between requirements and their
priorities.
 Report the status of the requirements (e.g., the
number, percentage, and state of the
requirements and requirements categories).
 Trace the requirements (e.g., to the associated
architecture, design, implementation, and test
work products).
115
REQUIREMENTS VALIDATION
 During this task, the RE teams validate the
correctness of the analyzed requirements
with their stakeholders and make any
necessary corrections.
 This is an ongoing task
116
REQUIREMENTS VALIDATION
 Identify a representative sample of all major
stakeholder types (e.g., customers, users,
maintainers, operators, subject matter experts,
marketers, and certifiers) to validate the
requirements.
 Ensure these stakeholders validate the
correctness of the requirements.
 Iterate to fix any requirements problems.
 Certify that the requirements are an acceptable
description of the system, software application,
or component to be implemented.
117
RELATED TASKS FROM OTHER DISCIPLINES
 Scope Management is the management task
that manages requirements changes that
could significantly change the scope of the
endeavor.
 Requirements Verification is the quality
engineering task that controls the quality of
the requirements and other requirements
work products such as requirements models
and requirements specifications.
118
RELATED TASKS FROM OTHER DISCIPLINES
 Requirements Configuration Control is the
configuration management task that
manages and evaluates the impact of
proposed changes to base-lined
requirements and other requirements work
products.
119
RELATIONSHIP BETWEEN THESE TASKS
 Iterative in the sense that the same tasks will
typically need to be repeated on the same
work products in order to fix defects and
make other improvements.
 Incremental in the sense that most systems
are too large and complex to engineer all
requirements in a big-bang waterfall manner
before beginning the tasks of other
disciplines
120
RELATIONSHIP BETWEEN THESE TASKS
 Concurrent in the sense that:
 Requirements engineering tasks are performed
simultaneously with the tasks of many other
disciplines
 The requirements engineering teams rapidly
cycle between tasks while different members of
the requirements team concurrently perform
different tasks on different sets of requirements.
121
RELATIONSHIP BETWEEN THESE TASKS
 When developing large and complex systems,
different requirements engineering teams are
concurrently performing different requirements
engineering tasks on different components of the
system architecture at different levels of the
system architecture.
122
REQUIREMENTS TRACKING
 Requirements traceability is concerned with
documenting the life of a requirement and to
provide bi-directional traceability between
various associated requirements.
 It enables users to find the origin of each
requirement and track every change which
was made to this requirement.
 it may be necessary to document every
change made to the requirement
123
GOTEL AND FINKELSTEIN DEFINITION
 the ability to describe and follow the life of a
requirement, in both a forward and backward
direction (i.e. from its origin, through its
development and specification, to its
subsequent deployment and use, and
through periods of on-going refinement and
iteration in any of these phases)
124
8.1 TRACING WITHIN THE PROJECT
 Traceability
 Requirements are not stable, but continue to
develop
 Reasons for continued development
 New insights
 New customer needs
 Continued work
 New connections within the project
125
TRACEABILITY AS A SOLUTION:
 Provides a check that all important steps of
the development process have been carried
out
 Goals:
 Impact analysis, coverage analysis, use-of-
potential analysis, proof of implementation, use
of the requirement, etc.
 In order to ensure good traceability, it is
important to label the requirements precisely.
126
PRE – AND POST- TRACIBILITY
 A SRS (software requirements specification)
is traceable if the origin of each of its
requirements is clear and if it facilitates the
referencing of each requirement in future
development and enhancement
documentation
 each requirement to be traced to its origin in
other documents and to the software
component( s) satisfying the requirement.
127
128
TYPES OF TRACEABILITY
 backward from requirements traceability (pre-
traceability) implies that we know why every
requirement in the SRS (Software
Requirements Specification) exists. It implies
that each requirement explicitly references its
source in previous documents;
 forward from requirements traceability (post-
traceability) implies that we understand which
components of the software satisfy each
requirement. It demands that each requirement
in the SRS explicitly references a design
129
TYPES OF TRACEABILITY
 backward to requirements traceability (pre-
traceability) implies that every software
component explicitly references those
requirements that it helps to satisfy. It implies
that each requirement in the SRS has a unique
name or reference number;
 forward to requirements traceability (post-
traceability) implies that documents that
preceded the SRS can reference the SRS. Like
"back to requirements" traceability, this implies
that each requirement in the SRS has a unique
name or reference number;"
130
TYPES OF TRACEABILITY
 Horizontal tracing
 Horizontal traceability ensures that the
requirements are traceable to the test cases.
 vertical tracing
 Vertical traceability ensures that the requirements are
traceable to the components of the implemented system
and vice versa.
131
132
8.2 CHANGE MANAGEMENT
 Changes of the requirements (Change
Management)
 Changes are checked and decided on by a
Change Control Board
 Makes decisions regarding change requests
133
THE CHANGE CONTROL BOARD
 consists of
 Project management
 Development
 Quality assurance
 Business management, if applicable
 Customer, if applicable
 etc.
134
THE CHANGE CONTROL
 A structured process is necessary for
changes of requirements
 The analysis of the meaning of each change
is important. Hasty solutions are problematic.
 Large changes of the requirements can be
so serious that they represent a contractual
change.
135
8.3 METRICS
 Metrics make it possible to make a
quantifiable statement regarding the project
status and quality
 Classification figures must always be
compared to reference data
136
METRICS FOR REQUIREMENTS:
 Project costs
 Project tracking
 Project stability
 Process improvement
 Quality of the specification
 Number of errors
 Type of error
137
MEASUREMENT OF THE REQUIREMENTS
QUALITY
 Are the requirements correct?
 Are the requirements understandable?
 The higher the change rate, the more a
project is at risk
138
RISK MANAGEMENT
 Project risk management is the art and science
of identifying, analyzing, and responding to risk
throughout the life of a project and in the best
interests of meeting project objectives
 Risk management is often overlooked in
projects, but it can help improve project success
by helping select good projects, determining
project scope, and developing realistic
estimates
139
3.2 WHY RISK MANAGEMENT
 minimize the impact of project threats
 seize the opportunities that occur
 deliver your project on time, on budget and
with the quality results your project sponsor
demands
 team members will be much happier if they
do not enter a "fire fighting" mode
140
RISK MANAGEMENT GOLDEN ROLES
 Make Risk Management Part of Your Project
 Identify Risks Early in Your Project
 Communicate About Risks
 Consider Both Threats and Opportunities
 Clarify Ownership Issues
 Prioritize Risks
 Analyze Risks
141
RISK MANAGEMENT GOLDEN ROLES
 Plan and Implement Risk Responses
 Register Project Risks
142
REQUIREMENTS-RELATED RISKS
REQUIREMENTS ELICITATION
 Product vision and project scope
 Time spent on requirements development (a
rough guideline is to spend about 10 to 15
percent of your project effort on requirements
development activities )
 Completeness and correctness of
requirements specifications (apply the use-
case technique to elicit requirements by
focusing on user tasks)
143
REQUIREMENTS-RELATED RISKS
REQUIREMENTS ELICITATION
 Requirements for highly innovative
products (Emphasize market research, build
prototypes, and use customer focus groups )
 Defining non-functional requirements (Query
customers about quality characteristics )
 Customer agreement on product
requirements (Determine who the primary
customers are, Make sure you're relying on
the right people for decision-making authority
on the requirements )
144
REQUIREMENTS-RELATED RISKS
REQUIREMENTS ELICITATION
 Unstated requirements (Customers often
hold implicit expectations that are not
communicated or documented )
 Existing product used as the requirements
baseline (Document the requirements that
you discover through reverse engineering,
and have customers review those
requirements to ensure that they are correct
and still relevant )
145
REQUIREMENTS-RELATED RISKS
REQUIREMENTS ELICITATION
 Solutions presented as needs (The analyst
must drill down to understand the intent
behind a solution the customer has
presented )
146
REQUIREMENTS-RELATED RISKS
REQUIREMENTS ANALYSIS
 Requirements prioritization (Ensure that
every functional requirement, feature, or use
case is prioritized and allocated to a specific
system release or iteration )
 Technically difficult features (Evaluate the
feasibility of each requirement to identify
those that might take longer than anticipated
to implement )
147
REQUIREMENTS-RELATED RISKS
REQUIREMENTS ANALYSIS
 Unfamiliar technologies, methods,
languages, tools, or hardware (Don't
underestimate the learning curve of getting
up to speed with new techniques that are
needed to satisfy certain requirements )
148
REQUIREMENTS-RELATED RISKS
REQUIREMENTS SPECIFICATION
 Requirements understanding (Formal
inspections of requirements documents by
teams that include developers, testers, and
customers , experienced requirements
analysts , Models and prototypes )
 Time pressure to proceed despite
TBDs (Record the name of the person
responsible for closing each TBD and the
target date for resolution )
149
REQUIREMENTS-RELATED RISKS
REQUIREMENTS SPECIFICATION
 Ambiguous terminology (Create a data
dictionary that defines the data items and
structures )
 Design included in requirements (Review the
requirements to make sure they emphasize
what needs to be done to solve the business
problem, rather than stating how it will be
solved. )
150
REQUIREMENTS-RELATED RISKS
REQUIREMENTS VALIDATION
 Invalidated requirements (Gain commitment
from your customer representatives to
participate in requirements inspections )
 Inspection proficiency ( Train all team
members , Invite an experienced inspector )
151
REQUIREMENTS-RELATED RISKS
REQUIREMENTS MANAGEMENT
 Changing requirements ( defer
implementation of those requirements that
are most likely to change, and design the
system for easy modifiability )
 Requirements change process (not having a
defined change process, using an ineffective
change mechanism, and incorporating
changes that bypass the process )
152
REQUIREMENTS-RELATED RISKS
REQUIREMENTS MANAGEMENT
 Unimplemented requirements (The
requirements traceability matrix )
 Expanding project scope ( use incremental
delivery life cycle )
153

Contenu connexe

Tendances

Software Engineering Methodology
Software Engineering MethodologySoftware Engineering Methodology
Software Engineering MethodologyRajandeep Gill
 
Unified Process
Unified ProcessUnified Process
Unified Processguy_davis
 
Process model in SE
Process model in SEProcess model in SE
Process model in SEsuranisaunak
 
SE18_Lec 05_Agile Software Development
SE18_Lec 05_Agile Software DevelopmentSE18_Lec 05_Agile Software Development
SE18_Lec 05_Agile Software DevelopmentAmr E. Mohamed
 
Process improvement & service oriented software engineering
Process improvement & service oriented software engineeringProcess improvement & service oriented software engineering
Process improvement & service oriented software engineeringSweta Kumari Barnwal
 
Software quality program and establishiment cocepts
Software quality program and establishiment coceptsSoftware quality program and establishiment cocepts
Software quality program and establishiment coceptsGuruKrishnaTeja
 
Report on SOFTWARE DEVELOPMENT LIFE CYCLE SDLC
Report on SOFTWARE DEVELOPMENT LIFE CYCLE SDLC Report on SOFTWARE DEVELOPMENT LIFE CYCLE SDLC
Report on SOFTWARE DEVELOPMENT LIFE CYCLE SDLC Neetu Marwah
 
Software Engineering unit 5
Software Engineering unit 5Software Engineering unit 5
Software Engineering unit 5Abhimanyu Mishra
 
Ch2-Software Engineering 9
Ch2-Software Engineering 9Ch2-Software Engineering 9
Ch2-Software Engineering 9Ian Sommerville
 
Ch24-Software Engineering 9
Ch24-Software Engineering 9Ch24-Software Engineering 9
Ch24-Software Engineering 9Ian Sommerville
 
Ch26 - software engineering 9
Ch26 - software engineering 9Ch26 - software engineering 9
Ch26 - software engineering 9Ian Sommerville
 
Software Development Lifecycle: What works for you?
Software Development Lifecycle: What works for you?Software Development Lifecycle: What works for you?
Software Development Lifecycle: What works for you?Jauhari Ismail
 
Chapter3 part3-cmm-for-cis6516
Chapter3 part3-cmm-for-cis6516Chapter3 part3-cmm-for-cis6516
Chapter3 part3-cmm-for-cis6516ZUbaria Inayat
 
Se solns 9th edition
Se solns 9th editionSe solns 9th edition
Se solns 9th editionrajabaidyo
 

Tendances (17)

Software Engineering Methodology
Software Engineering MethodologySoftware Engineering Methodology
Software Engineering Methodology
 
Software development life cycle
Software development life cycleSoftware development life cycle
Software development life cycle
 
Unified Process
Unified ProcessUnified Process
Unified Process
 
Process model in SE
Process model in SEProcess model in SE
Process model in SE
 
SE18_Lec 05_Agile Software Development
SE18_Lec 05_Agile Software DevelopmentSE18_Lec 05_Agile Software Development
SE18_Lec 05_Agile Software Development
 
Process improvement & service oriented software engineering
Process improvement & service oriented software engineeringProcess improvement & service oriented software engineering
Process improvement & service oriented software engineering
 
Software process
Software processSoftware process
Software process
 
Software quality program and establishiment cocepts
Software quality program and establishiment coceptsSoftware quality program and establishiment cocepts
Software quality program and establishiment cocepts
 
Report on SOFTWARE DEVELOPMENT LIFE CYCLE SDLC
Report on SOFTWARE DEVELOPMENT LIFE CYCLE SDLC Report on SOFTWARE DEVELOPMENT LIFE CYCLE SDLC
Report on SOFTWARE DEVELOPMENT LIFE CYCLE SDLC
 
Software Engineering unit 5
Software Engineering unit 5Software Engineering unit 5
Software Engineering unit 5
 
Ch2-Software Engineering 9
Ch2-Software Engineering 9Ch2-Software Engineering 9
Ch2-Software Engineering 9
 
Ch24-Software Engineering 9
Ch24-Software Engineering 9Ch24-Software Engineering 9
Ch24-Software Engineering 9
 
Sda 6
Sda   6Sda   6
Sda 6
 
Ch26 - software engineering 9
Ch26 - software engineering 9Ch26 - software engineering 9
Ch26 - software engineering 9
 
Software Development Lifecycle: What works for you?
Software Development Lifecycle: What works for you?Software Development Lifecycle: What works for you?
Software Development Lifecycle: What works for you?
 
Chapter3 part3-cmm-for-cis6516
Chapter3 part3-cmm-for-cis6516Chapter3 part3-cmm-for-cis6516
Chapter3 part3-cmm-for-cis6516
 
Se solns 9th edition
Se solns 9th editionSe solns 9th edition
Se solns 9th edition
 

En vedette

Introduction to Software Process
Introduction to Software ProcessIntroduction to Software Process
Introduction to Software ProcessFáber D. Giraldo
 
MBIT Graduate Project Presentation
MBIT Graduate Project PresentationMBIT Graduate Project Presentation
MBIT Graduate Project PresentationDimitris Kosmidis
 
Notes of Software engineering and Project Management
Notes of Software engineering and Project ManagementNotes of Software engineering and Project Management
Notes of Software engineering and Project ManagementNANDINI SHARMA
 
Project Planning in Software Engineering
Project Planning in Software EngineeringProject Planning in Software Engineering
Project Planning in Software EngineeringFáber D. Giraldo
 
Chapter 4 software project planning
Chapter 4 software project planningChapter 4 software project planning
Chapter 4 software project planningPiyush Gogia
 
Software engineering project management
Software engineering project managementSoftware engineering project management
Software engineering project managementjhudyne
 

En vedette (8)

Introduction to Software Process
Introduction to Software ProcessIntroduction to Software Process
Introduction to Software Process
 
MBIT Graduate Project Presentation
MBIT Graduate Project PresentationMBIT Graduate Project Presentation
MBIT Graduate Project Presentation
 
Swe notes
Swe notesSwe notes
Swe notes
 
Project managemen concept
Project managemen conceptProject managemen concept
Project managemen concept
 
Notes of Software engineering and Project Management
Notes of Software engineering and Project ManagementNotes of Software engineering and Project Management
Notes of Software engineering and Project Management
 
Project Planning in Software Engineering
Project Planning in Software EngineeringProject Planning in Software Engineering
Project Planning in Software Engineering
 
Chapter 4 software project planning
Chapter 4 software project planningChapter 4 software project planning
Chapter 4 software project planning
 
Software engineering project management
Software engineering project managementSoftware engineering project management
Software engineering project management
 

Similaire à Lecture 4

Requirement Engineering Processes & Eliciting Requirement
Requirement Engineering Processes & Eliciting Requirement Requirement Engineering Processes & Eliciting Requirement
Requirement Engineering Processes & Eliciting Requirement AqsaHayat3
 
Business Requirements development
Business Requirements development Business Requirements development
Business Requirements development Mark Opanasiuk
 
Business Analyst Overview
Business Analyst OverviewBusiness Analyst Overview
Business Analyst OverviewSalil Vaidya
 
Software Requirement Specification
Software Requirement SpecificationSoftware Requirement Specification
Software Requirement SpecificationVishal Singh
 
Software Requirements (3rd Edition) summary
Software Requirements (3rd Edition) summarySoftware Requirements (3rd Edition) summary
Software Requirements (3rd Edition) summaryAhmed Kamel Taha
 
Requirement Analysis & Specification sharbani bhattacharya
Requirement Analysis & Specification sharbani bhattacharyaRequirement Analysis & Specification sharbani bhattacharya
Requirement Analysis & Specification sharbani bhattacharyaSharbani Bhattacharya
 
Ch 3 -continued.pptx
Ch 3 -continued.pptxCh 3 -continued.pptx
Ch 3 -continued.pptxbalewayalew
 
Ch 2-RE-process.pptx
Ch 2-RE-process.pptxCh 2-RE-process.pptx
Ch 2-RE-process.pptxbalewayalew
 
User Requirements, Functional and Non-Functional Requirements
User Requirements, Functional and Non-Functional RequirementsUser Requirements, Functional and Non-Functional Requirements
User Requirements, Functional and Non-Functional RequirementsMark Opanasiuk
 
The Strategic Business Analyst: Aligning Projects with Organizational Goals
The Strategic Business Analyst: Aligning Projects with Organizational GoalsThe Strategic Business Analyst: Aligning Projects with Organizational Goals
The Strategic Business Analyst: Aligning Projects with Organizational GoalsCorporate Education Group (CEG)
 
SAD_UnitII.docx
SAD_UnitII.docxSAD_UnitII.docx
SAD_UnitII.docx8759000398
 
Business Analyst Job Description
Business Analyst Job DescriptionBusiness Analyst Job Description
Business Analyst Job Descriptiondavisjw
 
Business Analysis: Key Concepts and Deliverables
Business Analysis: Key Concepts and DeliverablesBusiness Analysis: Key Concepts and Deliverables
Business Analysis: Key Concepts and DeliverablesProduct School
 
chapter 2-Business Analysis Key Concepts.pdf
chapter 2-Business Analysis Key Concepts.pdfchapter 2-Business Analysis Key Concepts.pdf
chapter 2-Business Analysis Key Concepts.pdfyigerem
 
Agile Project Methodology.pptx
Agile Project Methodology.pptxAgile Project Methodology.pptx
Agile Project Methodology.pptxAnandPrasad84
 
Software Development Process - REQUIREMENTS ANALYSIS / ANALYSIS OF TECHNICAL...
Software Development Process -  REQUIREMENTS ANALYSIS / ANALYSIS OF TECHNICAL...Software Development Process -  REQUIREMENTS ANALYSIS / ANALYSIS OF TECHNICAL...
Software Development Process - REQUIREMENTS ANALYSIS / ANALYSIS OF TECHNICAL...Mark John Lado, MIT
 
requirement analysis characteristics
requirement analysis characteristics requirement analysis characteristics
requirement analysis characteristics Helmy Faisal
 

Similaire à Lecture 4 (20)

Requirement Engineering Processes & Eliciting Requirement
Requirement Engineering Processes & Eliciting Requirement Requirement Engineering Processes & Eliciting Requirement
Requirement Engineering Processes & Eliciting Requirement
 
Business Requirements development
Business Requirements development Business Requirements development
Business Requirements development
 
Business Analyst Overview
Business Analyst OverviewBusiness Analyst Overview
Business Analyst Overview
 
Unit 2
Unit 2Unit 2
Unit 2
 
Essay questions
Essay questionsEssay questions
Essay questions
 
Software Requirement Specification
Software Requirement SpecificationSoftware Requirement Specification
Software Requirement Specification
 
Software Requirements (3rd Edition) summary
Software Requirements (3rd Edition) summarySoftware Requirements (3rd Edition) summary
Software Requirements (3rd Edition) summary
 
Requirement Analysis & Specification sharbani bhattacharya
Requirement Analysis & Specification sharbani bhattacharyaRequirement Analysis & Specification sharbani bhattacharya
Requirement Analysis & Specification sharbani bhattacharya
 
Ch 3 -continued.pptx
Ch 3 -continued.pptxCh 3 -continued.pptx
Ch 3 -continued.pptx
 
Ch 2-RE-process.pptx
Ch 2-RE-process.pptxCh 2-RE-process.pptx
Ch 2-RE-process.pptx
 
User Requirements, Functional and Non-Functional Requirements
User Requirements, Functional and Non-Functional RequirementsUser Requirements, Functional and Non-Functional Requirements
User Requirements, Functional and Non-Functional Requirements
 
The Strategic Business Analyst: Aligning Projects with Organizational Goals
The Strategic Business Analyst: Aligning Projects with Organizational GoalsThe Strategic Business Analyst: Aligning Projects with Organizational Goals
The Strategic Business Analyst: Aligning Projects with Organizational Goals
 
SAD_UnitII.docx
SAD_UnitII.docxSAD_UnitII.docx
SAD_UnitII.docx
 
Business Analyst Job Description
Business Analyst Job DescriptionBusiness Analyst Job Description
Business Analyst Job Description
 
Business Analysis: Key Concepts and Deliverables
Business Analysis: Key Concepts and DeliverablesBusiness Analysis: Key Concepts and Deliverables
Business Analysis: Key Concepts and Deliverables
 
chapter 2-Business Analysis Key Concepts.pdf
chapter 2-Business Analysis Key Concepts.pdfchapter 2-Business Analysis Key Concepts.pdf
chapter 2-Business Analysis Key Concepts.pdf
 
Agile Project Methodology.pptx
Agile Project Methodology.pptxAgile Project Methodology.pptx
Agile Project Methodology.pptx
 
MOM on BA
MOM on BAMOM on BA
MOM on BA
 
Software Development Process - REQUIREMENTS ANALYSIS / ANALYSIS OF TECHNICAL...
Software Development Process -  REQUIREMENTS ANALYSIS / ANALYSIS OF TECHNICAL...Software Development Process -  REQUIREMENTS ANALYSIS / ANALYSIS OF TECHNICAL...
Software Development Process - REQUIREMENTS ANALYSIS / ANALYSIS OF TECHNICAL...
 
requirement analysis characteristics
requirement analysis characteristics requirement analysis characteristics
requirement analysis characteristics
 

Plus de Ahmed Alageed

Plus de Ahmed Alageed (17)

Project Time Management
Project Time Management Project Time Management
Project Time Management
 
Project Scope Management
Project Scope ManagementProject Scope Management
Project Scope Management
 
Project / Program / Portfolio Management and Processes Groups
Project / Program / Portfolio Management and Processes GroupsProject / Program / Portfolio Management and Processes Groups
Project / Program / Portfolio Management and Processes Groups
 
Project Management slide 2
Project Management slide 2Project Management slide 2
Project Management slide 2
 
Project Management Course slide 1
Project Management Course slide 1Project Management Course slide 1
Project Management Course slide 1
 
Lecture4
Lecture4Lecture4
Lecture4
 
Requirement Engineering Lec.1 & 2 & 3
Requirement Engineering Lec.1 & 2 & 3Requirement Engineering Lec.1 & 2 & 3
Requirement Engineering Lec.1 & 2 & 3
 
Lecture 5
Lecture 5 Lecture 5
Lecture 5
 
Agile Method - Lec 1-2-3
Agile Method - Lec 1-2-3Agile Method - Lec 1-2-3
Agile Method - Lec 1-2-3
 
Ch06
Ch06Ch06
Ch06
 
Ch05
Ch05Ch05
Ch05
 
Ch07
Ch07Ch07
Ch07
 
Ch04
Ch04Ch04
Ch04
 
Software Process Models
Software Process ModelsSoftware Process Models
Software Process Models
 
Lecture 3
Lecture 3Lecture 3
Lecture 3
 
Lecture 2
Lecture 2 Lecture 2
Lecture 2
 
Software Project Managment
Software Project ManagmentSoftware Project Managment
Software Project Managment
 

Dernier

Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...DianaGray10
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPathCommunity
 
Do we need a new standard for visualizing the invisible?
Do we need a new standard for visualizing the invisible?Do we need a new standard for visualizing the invisible?
Do we need a new standard for visualizing the invisible?SANGHEE SHIN
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6DianaGray10
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxGDSC PJATK
 
Things you didn't know you can use in your Salesforce
Things you didn't know you can use in your SalesforceThings you didn't know you can use in your Salesforce
Things you didn't know you can use in your SalesforceMartin Humpolec
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintMahmoud Rabie
 
Spring24-Release Overview - Wellingtion User Group-1.pdf
Spring24-Release Overview - Wellingtion User Group-1.pdfSpring24-Release Overview - Wellingtion User Group-1.pdf
Spring24-Release Overview - Wellingtion User Group-1.pdfAnna Loughnan Colquhoun
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8DianaGray10
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesDavid Newbury
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1DianaGray10
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaborationbruanjhuli
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UbiTrack UK
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding TeamAdam Moalla
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfAijun Zhang
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024SkyPlanner
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7DianaGray10
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAshyamraj55
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesMd Hossain Ali
 

Dernier (20)

Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation Developers
 
Do we need a new standard for visualizing the invisible?
Do we need a new standard for visualizing the invisible?Do we need a new standard for visualizing the invisible?
Do we need a new standard for visualizing the invisible?
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptx
 
Things you didn't know you can use in your Salesforce
Things you didn't know you can use in your SalesforceThings you didn't know you can use in your Salesforce
Things you didn't know you can use in your Salesforce
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership Blueprint
 
Spring24-Release Overview - Wellingtion User Group-1.pdf
Spring24-Release Overview - Wellingtion User Group-1.pdfSpring24-Release Overview - Wellingtion User Group-1.pdf
Spring24-Release Overview - Wellingtion User Group-1.pdf
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond Ontologies
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdf
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
 

Lecture 4

  • 1. SOFTWARE REQUIREMENT ENGINEERING Prepared By: Ahmed Alageed 1 4- RESPONSIBILITIES AND ROLES
  • 2. LEARNING TARGET  What basic roles are there in Requirements Engineering?  What is a stakeholder?  What are the tasks of Requirements Engineering?  What is the task of a Professional for Requirements Engineering?  What characterizes a Professional for Requirements Engineering? 2
  • 3. 4.1 BASIC ROLES  Client (= customer)  a customer is an individual or organization who derives either direct or indirect benefit from a product  The client formulates his needs ( Business Requirement , User Requirement)  Contractor (= supplier)  The contractor delivers solutions (RA) 3
  • 4. STAKEHOLDER  A stakeholder is a person or a role that has an interest  Stakeholders can be either natural persons, legal entities or abstract persons  Stakeholders often have conflicts of interest among each other  Important: Identification of all stakeholders in order to take adequate consideration of all perspectives 4
  • 5. THE CUSTOMER-DEVELOPMENT PARTNERSHIP ( CUSTOMER RIGHTS )  To Expect Analysts to Speak Your Language  To Have Analysts Learn About Your Business and Objectives  To Expect Analysts to Write a Software Requirements Specification  To Receive Explanations of Requirements Work Products  To Expect Analysts and Developers to Treat You with Respect 5
  • 6. THE CUSTOMER-DEVELOPMENT PARTNERSHIP ( CUSTOMER RIGHTS )  To Describe Characteristics That Make the Product Easy to Use  To Be Given Opportunities to Adjust Requirements to Permit Reuse  To Receive Good-Faith Estimates of the Costs of Changes  To Receive a System That Meets Your Functional and Quality Needs 6
  • 7. THE CUSTOMER-DEVELOPMENT PARTNERSHIP ( CUSTOMER RESPONSIBILITIES )  To Educate Analysts and Developers About Your Business  To Spend the Time to Provide and Clarify Requirements  To Be Specific and Precise About Requirements  To Make Timely Decisions  To Respect a Developer's Assessment of Cost and Feasibility 7
  • 8. THE CUSTOMER-DEVELOPMENT PARTNERSHIP ( CUSTOMER RESPONSIBILITIES )  To Set Requirement Priorities  To Review Requirements Documents and Evaluate Prototypes  To Promptly Communicate Changes to the Requirements  To Follow the Development Organization's Change Process  To Respect the Requirements Engineering Processes the Analysts Use 8
  • 9. RA ROLES  Work collaboratively with customers, users, and system architects and designers to identify the real requirements for a planned system or software development effort to define the problem that needs to be solved.  Identifying the stated needs of customers and users.  Studying the business objectives 9
  • 10. RA ROLES  Collaborating with customers and users in a joint or cooperative environment to analyze the stated requirements, evolve better requirements, and prioritize them  Involving system architects in requirements development.  Utilizing an industry-strength automated requirements tool to support this work. 10
  • 11. RA ROLES  Work effectively with customers and users to manage new and changed requirements so that the project stays under control. Install a mechanism to control changes.  Be alert to new technologies that may help.  Facilitate the project’s reuse of artifacts and achieving repeatability. 11
  • 12. RA ROLES  Assist the project and its customers in envisioning a growth path from the first release or version of a product through a set of staged releases to the ultimate system or product.  Advise the project (and customer) of methods, techniques, and automated tools that are available to best support requirements-related project work and activities. 12
  • 13. RA ROLES  Use metrics to measure, track, and control requirements-related project work activities and results.  Be able to facilitate discussions and to mediate conflicts.  Study the domain of the area in which the system or software is being used. 13
  • 14. KNOWLEDGE OF A PROFESSIONAL FOR REQUIREMENTS ENGINEERING:  Skill of moderation  Self-confident manner  Ability to convince  Language skills  Ability to communicate  Precision  Analytical, clear thinking  Ability to act in a structured way  Methodological competence  Stress resistance 14
  • 15. 4.2 TASKS OF REQUIREMENTS ENGINEERING  Analysis of business processes  Identification and analysis of requirements  Quality assurance of requirements and specifications  Creation of the requirements specification  Risk analysis The Professional for Requirements Engineering identifies wishes and aims. 15
  • 16. ANALYSIS OF BUSINESS PROCESSES  Analyze the business context Include the following tasks:  Analyze the customer organization’s business enterprise to understand the:  Business model.  Organizational structure and relationships.  Technology currently being used.  Relevant planned improvements. 16
  • 17. ANALYSIS OF BUSINESS PROCESSES  Analyze the competitor organizations that produce competing systems to:  Identify, profile, analyze, and understand the competitors.  See how the planned system [upgrade] will improve the customer organization’s business enterprise and help it compete. 17
  • 18. ANALYSIS OF BUSINESS PROCESSES  Analyze current and potential/planned marketplaces  Analyze critical technologies  Analyze current and intended future user communities (to understand their needs and desires and determine how the system might improve their tasks and workflows) 18
  • 19. ANALYSIS OF BUSINESS PROCESSES  Analyze the stakeholders to:  Identify different stakeholder persons, roles, organizations, and systems.  Profile them including categorizing them into well-defined and well understood groups.  Understand their needs, desires, responsibilities, and tasks. 19
  • 20. ANALYSIS OF BUSINESS PROCESSES  Develop a business case to determine whether the system [enhancement] should be developed by  Determining is costs and benefits  Comparing its merits relative to those of competing systems. 20
  • 21. ANALYSIS OF BUSINESS PROCESSES  VISIONING During this task, the main RE team collaborates with key stakeholders to produce a vision of the new system Define the system’s mission. Determine the business problems and opportunities to be solved by the system. Determine the most important stakeholder needs to be fulfilled by the system. 21
  • 22. VISIONING Determine the most important business, functional, and quality goals of the system. Determine any major business, technical, and legal/regulatory constraints on the system.  Use this information to build a consensus among key system stakeholders regarding the vision of the system to lay a foundation on which the system requirements can be engineered. 22
  • 23. IDENTIFICATION AND ANALYSIS OF REQUIREMENTS  Requirement Identification : During this task, the RE teams identify potential requirements include:  Identify sources of requirements (e.g., stakeholders, documents, legacy systems, problem reports, etc).  Elicit needs, goals, desires, and requirements from a representative sample of all major stakeholder types 23
  • 24. REQUIREMENT IDENTIFICATION  Gather potential requirements from existing documents describing legacy or competing systems, problem reports, marketing surveys, and other sources.  Invent new requirements so that the system will be truly better than the legacysystems it will replace and therefore worth building. Invention is a critically important, though underutilized, technique for identifying requirements, and is often the difference between a highly successful system and a marginally successful system. 24
  • 25. REQUIREMENT IDENTIFICATION  Transform stakeholder desires, expectations, and needs into informal, textual, potential requirements. 25
  • 26. REQUIREMENTS IDENTIFICATION  During this task, the RE teams identify potential requirements. This task typically includes the following subtasks:  Identify sources of requirements (e.g., takeholders, documents, legacy systems,problem reports, etc).  Elicit needs, goals, desires, and requirements from a representative sample of all major stakeholder types 26
  • 27. REQUIREMENTS IDENTIFICATION  Gather potential requirements from existing documents describing legacy or competing systems, problem reports, marketing surveys, and other sources.  Invent new requirements so that the system will be truly better than the legacy systems it will replace and therefore worth building  Transform stakeholder desires, expectations, and needs into informal, textual, potential requirements. 27
  • 28. REQUIREMENTS REUSE  During this task, the RE teams reuse all or part of preexisting requirements work products. This task typically includes the following subtasks:  Identify any potentially relevant reusable requirements work products (e.g., individual requirements, requirements templates, requirements diagrams, requirements models, and requirements specifications complete work products + parts of work products 28
  • 29. REQUIREMENTS REUSE  Evaluate the identified reusable requirements work products for relevancy to the current endeavor.  Tailor the relevant identified reusable requirements work products to meet the needs of the current endeavor.  Reuse the tailored reusable work products by incorporating them into the current endeavor’s requirements work products. 29
  • 30. REQUIREMENTS ANALYSIS  During this task, the RE teams analyze the identified and reused requirements. Include:  Study, categorize, decompose and organize, model, quantify, refine, prioritize, justify, and trace each requirement to its source(s).  Transform informal textual requirements into semiformal or formal requirements (if formal methods are used). 30
  • 31. REQUIREMENTS ANALYSIS  Negotiate the prioritization of requirements with the requirements stakeholders, and use the negotiated prioritization to help schedule the implementation of the requirements. Note that this subtask is often performed concurrently with the requirements validation task.  Verify any related assumptions. 31
  • 32. REQUIREMENTS ANALYSIS  Transform potential raw requirements and related information into real requirements that have the necessary quality characteristics such as clarity (i.e.,lack of ambiguity), completeness, consistency, correctne ss, feasibility (e.g.,technical, financial, schedule, etc.), verifiabil ity, and understandability.  Ensure that the requirements are sufficiently well understood that they can be properly specified. 32
  • 33. REQUIREMENTS PROTOTYPING (OPTIONAL)  During this task, the RE teams generate requirements engineering prototypes. Include :  Produce one or more requirements prototypes (e.g., paper or wireframe prototypes of user interfaces or executable models).  Evaluate these prototypes. This may involve analysis of static prototypes or execution and evaluation of dynamic prototypes. 33
  • 34. REQUIREMENTS PROTOTYPING (OPTIONAL)  Use these prototypes to:  Help identify new requirements such as functional, data, and quality requirements regarding user interfaces.  Better understand existing requirements.  Identify defects in the existing requirements that drove the development of these prototypes.  Support the analysis of these requirements. 34
  • 35. REQUIREMENT ANALYSIS PROCEDURE 1. Analysis of the needs 2. Description of the solution 3. Cost estimate and prioritization 35
  • 36. 7.2 METHODS AND TECHNIQUES  Different aspects of a system are represented through different views  Models are developed through suitable methods of analysis  Differentiation between types of models  Requirements models  Solution models 36
  • 37. DIFFERENT MODELS (STRUCTURED)  Context model  Functional decomposition  Data flow model  State transition model  Petri Net  Entity Relationship Model 37
  • 38. CONTEXT MODEL  Is a diagram that represents the actors outside a system that could interact with that system  This diagram is the highest level view of a system.  SCDs show a system, often software-based, as a whole and its inputs and outputs from/to external factors 38
  • 39. 39
  • 40. FUNCTIONAL DECOMPOSITION  A Functional Decomposition Diagram enables you to view your system functions in an hierarchical structure 40
  • 41. 41
  • 42. DATA FLOW MODEL  DFDs show the flow of data from external entities into the system, showed how the data moved from one process to another, as well as its logical storage 42
  • 43. 43
  • 44. STATE TRANSITION MODEL  describe the behavior of systems  State diagrams require that the system described is composed of a finite number of state 44
  • 45. 45
  • 46. PETRI NET  Like the activity diagram 46
  • 47. ENTITY RELATIONSHIP MODEL  is an abstract and conceptual representation of data. Entity-relationship modeling is a database modeling method,  used to produce a type of conceptual schema or semantic data model of a system, often a rational database, and its requirements in a top-down fashion 47
  • 48. 48
  • 49. 7.3 OBJECT-ORIENTED ANALYSIS  UML (Unified Modeling Language)  UML provides diagrams for different views of the system  Use case diagrams, class diagrams, activity diagrams, state diagrams, object diagrams, sequence diagram, component diagrams, package diagrams, etc. 49
  • 50. USE-CASE DIAGRAM  Use-Case diagrams are probably the simplest diagramming notation within the UML  Use-Case diagrams model the operations of the system as perceived by an outside user  i.e. They model ‘what’ the system does rather than ‘how’ it does it ! 50
  • 51. USE-CASE DIAGRAM  The two primary elements of UC diagrams are Actors and Use-Cases  Actors - (shown as stick-men on diagrams)  Model the outside users of the system  Actors are not always humans, can be other computer systems; external devices etc.  A single user may actually be a different actor at the same time  Many users may be the same actor at the same time  It is actors that initiate a particular use-case 51
  • 52. USE-CASE DIAGRAM  Use-Cases - (shown as an ellipse on diagrams)  A use-case is a unit of an externally visible operation (i.e. a single use of the system)  Each use-case is orthogonal within the model (i.e. each use-case can be performed independently and in any order)  Each use-case can connect to one or more actors by a solid line, this indicates an association between an actor and that particular use of the system 52
  • 54. REFINING USE-CASE DIAGRAMS  Once an initial use-cases have been documented they can be refined  The refining of a Use-Case diagram can help simplify and remove unnecessary redundancy  There are three main ways in which refinement can be performed (usually aided by reading descriptions, see later)  Identification of shared sequences of operations  Identification of alternative actions within single use- cases  Identification of common behavior between use-cases 54
  • 55. USING <<INCLUDE>> ASSOCIATIONS  This type of association allows a shared sequence of operations to be included in several use-cases  Simplifies a use-case diagram by factoring out common operations  When a use-case is included within another use-case the operations are always incorporated  The operations from the included use-case are NOT interleaved, they exist as a single block  Including a use-case is similar to calling a sub- 55
  • 57. USING <<EXTEND>> ASSOCIATIONS  This type of association allows a sequence of operations to be conditionally included in a use- case  Improves the model by identifying less common alternatives to operations normally performed  Extensions are typically attached to an extension-point within the use-case which is being extended  If a specific condition is true at the extension point then the extending use-cases operations are included, otherwise they are not  Similar to an ‘if-then’ construct within a program57
  • 59. USING GENERALIZATION/SPECIALIZATION  This type of association allows common behavior to be extracted into generalized use-cases  The common behavior is then inherited by specialized use-cases  Additional steps in the specialized use-cases can be interleaved with those inherited from the generalized use-case  A specialized use-case inherits associations from its generalized use-case, and can be substituted for its generalized use-case
  • 61. INTERNALS OF USE-CASES  Use-Case diagrams do not show internal workings of each use-case  These can be documented using other UML diagrams or natural language  Tend to use natural language during analysis and UML diagrams later in the lifecycle  Natural language descriptions should be well- formed and consist of an agreed upon format within the s/w company
  • 62. A FORMAT DEFINITION FOR TEXTUAL USE- CASE DESCRIPTIONS List all pre-conditions X-reference name of any generalized use-case List main sequence of operations (numbered) Show included use-cases as single step, X-ref the name List alternatives X-ref the sequence number of extension point Specify condition for extension to be utilized X-reference the sequence number of re-entrance point
  • 63. EXAMPLE DOCUMENTATION OF A USE- CASE Use-case : debit account Inherits from : Transfer Funds pre-condition: account number exists 1. Read amount to be debited 2. Perform check (Check Account Balance) 3. Deduct amount to be debited 4. Report success code
  • 64. USE-CASE SUMMARY  Accurate requirements are very important to the success of analysis and design  Use-Case diagrams can be used to model requirements as seen from an external, or users’ point of view  Actors & Use-Cases are the two primary elements of a Use-Case diagram  Refinement of a Use-Case diagram helps remove redundancy  Internals of each use-case can be defined using other UML diagrams and/or natural language
  • 65. ACTIVITY DIAGRAM  Activity diagram is used to display the sequence of activities  Activity Diagrams show the workflow from a start point to the finish point detailing the many decision paths that exist in the progression of events contained in the activity  They may be used to detail situations where parallel processing may occur in the execution of some activities  Activity Diagrams are useful for Business Modeling where they are used for detailing the processes involved in business activities65
  • 66. 66
  • 67. ACTIVITY NODE  An activity is the specification of a parameterized sequence of behavior  An activity is shown as a round-cornered rectangle enclosing all the actions, control flows and other elements that make up the activity 67
  • 68. ACTION NODE  An action represents a single step within an activity  Actions are denoted by round-cornered rectangles. 68
  • 69. ACTION CONSTRAINTS  Constraints can be attached to an action  This sample shows an action with local pre and post- conditions. 69
  • 70. CONTROL FLOW  A control flow shows the flow of control from one action to the next one  Its notation is a line with an arrowhead. 70
  • 71. INITIAL NODE  An initial or start node is depicted by a large black spot, as depicted below 71
  • 72. ACTIVITY FINAL NODE  There are two types of final node  activity final  flow final nodes  The activity final node is depicted as a circle with a dot inside 72
  • 73. FLOW FINAL NODE  The flow final node is depicted as a circle with a cross inside  The difference between the two node types is that the flow final node denotes the end of a single control flow  The activity final node denotes the end of all control flows within the activity 73
  • 74. SAMPLES OF ACTIVITY AND FLOW FINAL NODES  A flow dies without ending the whole activity  A flow final node terminates its own path not the whole activity  It is shown as a circle with an X through it 74
  • 75. BASIC CONTROL FLOWS  Sequential Control Flow  Branch Control Flow  Iteration Control Flow 75
  • 76. SEQUENTIAL CONTROL FLOW  A Sequence of Activities Node  Unconditional Flow 76
  • 77. BRANCH CONTROL FLOW  Decision nodes and merge nodes have the same notation - using a diamond shape  They can both be named  The control flows coming away from a decision node will have guard conditions which will allow control to flow if the guard condition is met 77
  • 78. DECISION NODE  Decisions are used when you want to execute a different sequence of actions depending on a condition  Decisions are drawn as diamond-shaped nodes with one incoming edge and multiple outgoing edges  Each branched edge contains a guard condition written in brackets  Guard conditions determine which edge is taken after a decision node 78
  • 79. 79
  • 80. MERGE NODE  The branched flows join together at a merge node, which marks the end of the conditional behavior started at the decision node  Merges are also shown with diamond- shaped nodes, but they have multiple incoming edges and one outgoing edge 80
  • 81. USING MERGE NODE IN UML2  In UML 2.0, it's better to be as clear as possible and to show merge nodes 81
  • 83. ITERATION CONTROL FLOW  A loop is a sequence of activity nodes which is specified once but which may be carried out several times in succession 83
  • 84. CONCURRENT ACTIVITIES  Forks and Joins have the same notation – using either a horizontal or vertical bar  They indicate the start and end of concurrent threads of control 84
  • 85. CONCURRENT ACTIVITY  When actions occur in parallel, it doesn't necessarily mean they will finish at the same time  In fact, one task will most likely finish before the other  However, the join prevents the flow from continuing past the join until all incoming flows are complete 85
  • 86. 86
  • 89. 7.4 COST ESTIMATES  Cost estimates connect Requirements Engineering with the project management Types of estimate  Costs  Time  Requirements  Quality  Cost estimates help to recognize the cost for change 89
  • 90. ESTIMATION PROCEDURE  Conclusions by analogy  Algorithmic procedure  Function point procedure  bottom-up Approach  Estimation procedures are always based on historical data and framework conditions 90
  • 91. 7.5 PRIORITIZATION  Why prioritization?  Prioritization is a way to deal with competing demands for limited resources  A project manager must balance the desired project scope against the constraints of schedule, budget, staff, and quality goals. One way to accomplish this is to drop—or to defer to a later release—low-priority 91
  • 92. GAMES PEOPLE PLAY WITH PRIORITIES  Customers and developers both should provide input to requirements prioritization  customers will establish perhaps 85 percent of the requirements as high priority, 10 percent as medium, and 5 percent as low.  High priority mean high risk. 92
  • 93. ENCOURAGE CUSTOMER TO IDENTIFY LOW PRIORITY REQUIREMENT  ask questions such as the following:  Is there some other way to satisfy the need that this requirement addresses?  What would the consequence be of omitting or deferring this requirement?  What would the impact be on the project's business objectives if this requirement weren't implemented immediately?  Why would a user be unhappy if this requirement were deferred to a later release? 93
  • 94. A PRIORITIZATION SCALE  common prioritization approach groups requirements into three categories  One way to assess priority is to consider the two dimensions of importance and urgency  High priority requirements are both important (the user needs the capability) and urgent (the user needs it in the next release). Contractual or legal obligations might dictate that the requirement must be included, or there might be compelling business reasons to implement it promptly. 94
  • 95. A PRIORITIZATION SCALE  Medium priority requirements are important (the user needs the capability) but not urgent (they can wait for a later release).  Low priority requirements are not important (the user can live without the capability if necessary) and not urgent (the user can wait, perhaps forever).  Requirements in the fourth quadrant appear to be urgent but they really aren't important. Don't waste your time working on these. They don't add sufficient value to the product. 95
  • 96. Important Not Important Urgent High Priority Low Priority Not Urgent Medium Priority Don't do these! 96 REQUIREMENTS PRIORITIZATION BASED ON IMPORTANCE AND URGENCY
  • 97. PRIORITIZATION BASED ON VALUE, COST, AND RISK  The typical participants in the prioritization process include:  The project manager, who leads the process, arbitrates conflicts, and adjusts input from the other participants if necessary  Customer representatives, such as product champions or marketing staff, who supply the benefit and penalty ratings  Development representatives, such as team technical leads, who provide the cost and risk ratings 97
  • 98. STEPS OF THE PRIORITIZATION MODEL  Step 1:  List in the spreadsheet all the features, use cases, or requirements that you want to prioritize; All the items must be at the same level of abstraction—don't mix functional requirements with product features.  If certain features are logically linked (for example, you'd implement feature B only if feature A were included),  list only the driving feature in the analysis.  If you have more items than that, group related features together to create a manageable initial list. 98
  • 99. STEPS OF THE PRIORITIZATION MODEL  Have your customer representatives estimate the relative benefit that each feature would provide to the customer or to the business on a scale of 1 to 9. A rating of 1 indicates that no one would find it useful and 9 means it would be extremely valuable. These benefit ratings indicate alignment of the features with the product's business requirements. 99
  • 100.  Estimate the relative penalty that the customer or business would suffer if the feature were not included. Again, use a scale of 1 to 9. A rating of 1 means that no one will be upset if it's excluded; 9 indicates a serious downside. When assigning penalty ratings, consider how unhappy the customers will be if a specific capability isn't included. Ask yourselves questions such as the following: 100 STEPS OF THE PRIORITIZATION MODEL
  • 101. ESTIMATE THE RELATIVE PENALTY  Would your product suffer in comparison with other products that do contain that capability?  Would there be any legal or contractual consequences?  Would you be violating some government or industry standard?  Would users be unable to perform some necessary or expected functions?  Would it be a lot harder to add that capability later as an enhancement?  Would problems arise because marketing has promised a feature to satisfy some potential 101
  • 102. STEPS OF THE PRIORITIZATION MODEL  By default, benefit and penalty are weighted equally. As a refinement, you can change the relative weights for these two factors 102
  • 103. STEPS OF THE PRIORITIZATION MODEL  Have developers estimate the relative cost of implementing each feature, again on a scale of 1 (quick and easy) to 9 (time consuming and expensive). Developers estimate the cost ratings based on the feature's complexity, the extent of user interface work required, the potential ability to reuse existing code, the amount of testing and documentation that will be needed, and so forth. 103
  • 104. STEPS OF THE PRIORITIZATION MODEL  Similarly, have developers rate the relative degree of technical or other risks associated with each feature on a scale of 1 to 9. Technical risk is the probability of not getting the feature right on the first try. A rating of 1 means that you can program it in your sleep. A 9 indicates serious concerns about feasibility, the lack of staff with the necessary expertise, or the use of unproven or unfamiliar tools and technologies. 104
  • 105. STEPS OF THE PRIORITIZATION MODEL  Once you've entered all the estimates into the spreadsheet, it will calculate a priority value for each feature using the following formula:  priority = value % (cost % * cost weight) + (risk % * risk weight) 105
  • 106. SPECIFICATION OF REQUIREMENTS  In the specification, requirements are specified in a structured way and are modeled separately.  The specification serves to track and manage requirements. 106
  • 107. CREATION OF THE REQUIREMENTS SPECIFICATION  During this task, the RE teams generate and publish analyzed and/or validated requirements in paper or electronic requirements specification documents. Include:  System, subsystem, software, and hardware requirements specifications containing the individual requirements and associated ancillary information. 107
  • 108. CREATION OF THE REQUIREMENTS SPECIFICATION  Operational concept documents (OCDs) containing use cases, misuse or abuse cases, and usage scenarios.  Glossary and Domain Object Model to properly define the meaning of the terms used in the requirements 108
  • 109. CREATION OF THE REQUIREMENTS SPECIFICATION  Distribute the requirements specifications to their audiences or make access available to them.  Iterate the requirements specifications as a result of informal feedback. Note that more formal feedback will come as part of the requirements verification subtask of quality engineering. 109
  • 110. STANDARD CONTENTS OF A REQUIREMENTS DOCUMENT  Introduction  Secrecy clause  Regulations  Standards  Stakeholder  Purpose of the product  Description of the system 110
  • 111. STANDARD CONTENTS OF A REQUIREMENTS DOCUMENT  Functional requirements  Non-functional requirements  Assumptions  Dependencies  Risks  Safety requirements  Software Quality Attributes  Acceptance 111
  • 112. LEVEL OF SPECIFICATION  Requirements specifications  Are also called performance specifications  The creation should be the customer's task  Solution specifications  Are also called functional specifications  The basis for the further system development 112
  • 113. SPECIFICATION PROCEDURE  Specification as an activity for formalizing the results of the requirements analysis  Different degrees of formalization  Non-formal  Semi-formal  Formal 113
  • 114. REQUIREMENTS MANAGEMENT  During this task, the RE teams manage all requirements, regardless of their status.  Record and store the requirements and their attributes (i.e., metadata about the requirements) in an appropriate repository, database, or requirements management tool.  Control access (e.g., create, read, update, delete) to the requirements (e.g., based on metadata such as authorization to create/read/update/delete requirements by role, requirement state, requirement ownership, requirement responsibility, date of last change to the requirement, etc.). 114
  • 115. REQUIREMENTS MANAGEMENT  Negotiate with the stakeholders to eliminate any inconsistencies between requirements and their priorities.  Report the status of the requirements (e.g., the number, percentage, and state of the requirements and requirements categories).  Trace the requirements (e.g., to the associated architecture, design, implementation, and test work products). 115
  • 116. REQUIREMENTS VALIDATION  During this task, the RE teams validate the correctness of the analyzed requirements with their stakeholders and make any necessary corrections.  This is an ongoing task 116
  • 117. REQUIREMENTS VALIDATION  Identify a representative sample of all major stakeholder types (e.g., customers, users, maintainers, operators, subject matter experts, marketers, and certifiers) to validate the requirements.  Ensure these stakeholders validate the correctness of the requirements.  Iterate to fix any requirements problems.  Certify that the requirements are an acceptable description of the system, software application, or component to be implemented. 117
  • 118. RELATED TASKS FROM OTHER DISCIPLINES  Scope Management is the management task that manages requirements changes that could significantly change the scope of the endeavor.  Requirements Verification is the quality engineering task that controls the quality of the requirements and other requirements work products such as requirements models and requirements specifications. 118
  • 119. RELATED TASKS FROM OTHER DISCIPLINES  Requirements Configuration Control is the configuration management task that manages and evaluates the impact of proposed changes to base-lined requirements and other requirements work products. 119
  • 120. RELATIONSHIP BETWEEN THESE TASKS  Iterative in the sense that the same tasks will typically need to be repeated on the same work products in order to fix defects and make other improvements.  Incremental in the sense that most systems are too large and complex to engineer all requirements in a big-bang waterfall manner before beginning the tasks of other disciplines 120
  • 121. RELATIONSHIP BETWEEN THESE TASKS  Concurrent in the sense that:  Requirements engineering tasks are performed simultaneously with the tasks of many other disciplines  The requirements engineering teams rapidly cycle between tasks while different members of the requirements team concurrently perform different tasks on different sets of requirements. 121
  • 122. RELATIONSHIP BETWEEN THESE TASKS  When developing large and complex systems, different requirements engineering teams are concurrently performing different requirements engineering tasks on different components of the system architecture at different levels of the system architecture. 122
  • 123. REQUIREMENTS TRACKING  Requirements traceability is concerned with documenting the life of a requirement and to provide bi-directional traceability between various associated requirements.  It enables users to find the origin of each requirement and track every change which was made to this requirement.  it may be necessary to document every change made to the requirement 123
  • 124. GOTEL AND FINKELSTEIN DEFINITION  the ability to describe and follow the life of a requirement, in both a forward and backward direction (i.e. from its origin, through its development and specification, to its subsequent deployment and use, and through periods of on-going refinement and iteration in any of these phases) 124
  • 125. 8.1 TRACING WITHIN THE PROJECT  Traceability  Requirements are not stable, but continue to develop  Reasons for continued development  New insights  New customer needs  Continued work  New connections within the project 125
  • 126. TRACEABILITY AS A SOLUTION:  Provides a check that all important steps of the development process have been carried out  Goals:  Impact analysis, coverage analysis, use-of- potential analysis, proof of implementation, use of the requirement, etc.  In order to ensure good traceability, it is important to label the requirements precisely. 126
  • 127. PRE – AND POST- TRACIBILITY  A SRS (software requirements specification) is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in future development and enhancement documentation  each requirement to be traced to its origin in other documents and to the software component( s) satisfying the requirement. 127
  • 128. 128
  • 129. TYPES OF TRACEABILITY  backward from requirements traceability (pre- traceability) implies that we know why every requirement in the SRS (Software Requirements Specification) exists. It implies that each requirement explicitly references its source in previous documents;  forward from requirements traceability (post- traceability) implies that we understand which components of the software satisfy each requirement. It demands that each requirement in the SRS explicitly references a design 129
  • 130. TYPES OF TRACEABILITY  backward to requirements traceability (pre- traceability) implies that every software component explicitly references those requirements that it helps to satisfy. It implies that each requirement in the SRS has a unique name or reference number;  forward to requirements traceability (post- traceability) implies that documents that preceded the SRS can reference the SRS. Like "back to requirements" traceability, this implies that each requirement in the SRS has a unique name or reference number;" 130
  • 131. TYPES OF TRACEABILITY  Horizontal tracing  Horizontal traceability ensures that the requirements are traceable to the test cases.  vertical tracing  Vertical traceability ensures that the requirements are traceable to the components of the implemented system and vice versa. 131
  • 132. 132
  • 133. 8.2 CHANGE MANAGEMENT  Changes of the requirements (Change Management)  Changes are checked and decided on by a Change Control Board  Makes decisions regarding change requests 133
  • 134. THE CHANGE CONTROL BOARD  consists of  Project management  Development  Quality assurance  Business management, if applicable  Customer, if applicable  etc. 134
  • 135. THE CHANGE CONTROL  A structured process is necessary for changes of requirements  The analysis of the meaning of each change is important. Hasty solutions are problematic.  Large changes of the requirements can be so serious that they represent a contractual change. 135
  • 136. 8.3 METRICS  Metrics make it possible to make a quantifiable statement regarding the project status and quality  Classification figures must always be compared to reference data 136
  • 137. METRICS FOR REQUIREMENTS:  Project costs  Project tracking  Project stability  Process improvement  Quality of the specification  Number of errors  Type of error 137
  • 138. MEASUREMENT OF THE REQUIREMENTS QUALITY  Are the requirements correct?  Are the requirements understandable?  The higher the change rate, the more a project is at risk 138
  • 139. RISK MANAGEMENT  Project risk management is the art and science of identifying, analyzing, and responding to risk throughout the life of a project and in the best interests of meeting project objectives  Risk management is often overlooked in projects, but it can help improve project success by helping select good projects, determining project scope, and developing realistic estimates 139
  • 140. 3.2 WHY RISK MANAGEMENT  minimize the impact of project threats  seize the opportunities that occur  deliver your project on time, on budget and with the quality results your project sponsor demands  team members will be much happier if they do not enter a "fire fighting" mode 140
  • 141. RISK MANAGEMENT GOLDEN ROLES  Make Risk Management Part of Your Project  Identify Risks Early in Your Project  Communicate About Risks  Consider Both Threats and Opportunities  Clarify Ownership Issues  Prioritize Risks  Analyze Risks 141
  • 142. RISK MANAGEMENT GOLDEN ROLES  Plan and Implement Risk Responses  Register Project Risks 142
  • 143. REQUIREMENTS-RELATED RISKS REQUIREMENTS ELICITATION  Product vision and project scope  Time spent on requirements development (a rough guideline is to spend about 10 to 15 percent of your project effort on requirements development activities )  Completeness and correctness of requirements specifications (apply the use- case technique to elicit requirements by focusing on user tasks) 143
  • 144. REQUIREMENTS-RELATED RISKS REQUIREMENTS ELICITATION  Requirements for highly innovative products (Emphasize market research, build prototypes, and use customer focus groups )  Defining non-functional requirements (Query customers about quality characteristics )  Customer agreement on product requirements (Determine who the primary customers are, Make sure you're relying on the right people for decision-making authority on the requirements ) 144
  • 145. REQUIREMENTS-RELATED RISKS REQUIREMENTS ELICITATION  Unstated requirements (Customers often hold implicit expectations that are not communicated or documented )  Existing product used as the requirements baseline (Document the requirements that you discover through reverse engineering, and have customers review those requirements to ensure that they are correct and still relevant ) 145
  • 146. REQUIREMENTS-RELATED RISKS REQUIREMENTS ELICITATION  Solutions presented as needs (The analyst must drill down to understand the intent behind a solution the customer has presented ) 146
  • 147. REQUIREMENTS-RELATED RISKS REQUIREMENTS ANALYSIS  Requirements prioritization (Ensure that every functional requirement, feature, or use case is prioritized and allocated to a specific system release or iteration )  Technically difficult features (Evaluate the feasibility of each requirement to identify those that might take longer than anticipated to implement ) 147
  • 148. REQUIREMENTS-RELATED RISKS REQUIREMENTS ANALYSIS  Unfamiliar technologies, methods, languages, tools, or hardware (Don't underestimate the learning curve of getting up to speed with new techniques that are needed to satisfy certain requirements ) 148
  • 149. REQUIREMENTS-RELATED RISKS REQUIREMENTS SPECIFICATION  Requirements understanding (Formal inspections of requirements documents by teams that include developers, testers, and customers , experienced requirements analysts , Models and prototypes )  Time pressure to proceed despite TBDs (Record the name of the person responsible for closing each TBD and the target date for resolution ) 149
  • 150. REQUIREMENTS-RELATED RISKS REQUIREMENTS SPECIFICATION  Ambiguous terminology (Create a data dictionary that defines the data items and structures )  Design included in requirements (Review the requirements to make sure they emphasize what needs to be done to solve the business problem, rather than stating how it will be solved. ) 150
  • 151. REQUIREMENTS-RELATED RISKS REQUIREMENTS VALIDATION  Invalidated requirements (Gain commitment from your customer representatives to participate in requirements inspections )  Inspection proficiency ( Train all team members , Invite an experienced inspector ) 151
  • 152. REQUIREMENTS-RELATED RISKS REQUIREMENTS MANAGEMENT  Changing requirements ( defer implementation of those requirements that are most likely to change, and design the system for easy modifiability )  Requirements change process (not having a defined change process, using an ineffective change mechanism, and incorporating changes that bypass the process ) 152
  • 153. REQUIREMENTS-RELATED RISKS REQUIREMENTS MANAGEMENT  Unimplemented requirements (The requirements traceability matrix )  Expanding project scope ( use incremental delivery life cycle ) 153