Lecture4

SOFTWARE REQUIREMENT ENGINEERING

ALNEELAIN UNIVERSITY SOFTWARE ENGINEERING

DEPT.

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 analysisThe 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


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


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


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


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


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, correctness, feasibility (e.g.,technical, financial, schedule, etc.), verifiability, 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 PROCEDURE1. Analysis of the needs2. Description of the solution3. 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

http://upload.wikimedia.org/wikipedia/commons/c/cf/Finite_state_machine_example_with_comments.svg

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

http://upload.wikimedia.org/wikipedia/commons/7/72/ER_Diagram_MMORPG.png

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-case51

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 Statement

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-routine within a program

55

<<INCLUDE>> EXAMPLE

56

Open Account

Close Account

Credit Account

Debit Account

Print Statement

Accounts manager

Teller

ATM

Bank System

Check Account Balance<<include>

>

<<

include>

>

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 Statement

Accounts manager

Teller

ATM

Bank System


>

<<

include>

>

Reject Request

<<

exte

nd

>>

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 Statement

Accounts manager

Teller

ATM

Bank System


>

<<

include>

>Transfer Funds

Reject Request

<<

exte

nd

>>

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 alternativesX-ref the sequence number of extension pointSpecify condition for extension to be utilizedX-reference the sequence number of re-entrance point

EXAMPLE DOCUMENTATION OF A USE-CASE

Use-case : debit accountInherits from : Transfer Fundspre-condition: account number

exists1. Read amount to be debited2. Perform check (Check Account

Balance)3. Deduct amount to be debited4. 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 activities

65

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


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 customers but the team decided to omit it? 101


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


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


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 requirement123

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 component;

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 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


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


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