02- Software Requirements

1

بسم هللا الرحمن الرحيم

Prepared By:

Eng.\ Tarig Ahmed Khalid, M.Sc., PMP, CEC, CBAP

IT/ Project Management/ Business Analysis Consultant & Trainer

Software Requirements

2

Introduction

The Software Requirements Knowledge Area (KA) is concerned

with:

1. Requirements Elicitation

2. Requirements Analysis

3. Requirements Specification

4. Requirements Validation

It is widely acknowledged within the software industry that

software engineering projects are critically vulnerable when these

activities are poorly performed.

3

1. Software Requirements Fundamentals

2. Requirements Process





7. Practical Considerations

4








5

1.1 What is a Requirement?

A requirement is:

1. A condition or capability needed by a stakeholder to:

a. solve a problem, or

b. achieve an objective

2. A condition or capability that must be met or possessed by a

solution or solution component to satisfy a :

a. contract,

b. standard,

c. specification, or

d. other formally imposed documents

3. A documented representation of a condition or capability as in

(1) or (2)

IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology

6

1.2 What is a Software Requirement?

Software requirement is a property which must be exhibited in

order to solve some problem in the real world.

Software requirement is a property which must be exhibited by

software developed or adapted to solve a particular problem.

An essential property of all software requirements is that they must

be verifiable

7

1.3 Importance of Requirements

Requirements Management can be an extremely complex

discipline because of:

1. the numbers of stakeholders involved in the development

process

2. the precious use of resources.

Let us compare the following projects in terms of specifications

complexity:

Building a

Building a

VS.

8

Poor requirements management is likely to lead to some very

costly mistakes.

9

Requirements are classified into:

1. Business Requirements

2. Stakeholders Requirements

3. Solution Requirements

4. Transition Requirements

Business

requirements

Stakeholder requirements

Solution requirements

Transition requirements

Requirements evolve!

1.4 Types of Requirements

10

1.4.1 Business Requirements

Are higher-level statements of the goals, objectives, or needs of the

enterprise.

They describe :

1. The reasons why a project has been initiated

2. The objectives that the project will achieve

3. The metrics that will be used to measure its success.

Business requirements describe needs of the organization as a

whole, and not groups or stakeholders within it

Related to the organization’s executives & BOD

11

1.4.2 Stakeholders’ Requirements

Are statements of the needs of a particular stakeholder or class of

stakeholders.

They describe:

1. the needs that a given stakeholder has

and

2. how that stakeholder will interact with a solution.

Stakeholder requirements serve as a bridge between business

requirements and the various classes of solution requirements.

Business

Requirements

Solution

Requirements

Stakeholders’

Requirements

12

1.4.3 Solution Requirements

They describe the characteristics of a solution that meet business

requirements and stakeholder requirements.

They are frequently divided into:

a. Functional Requirements

b. Non-functional Requirements

13

a. Functional Requirements

– They describe the behavior and information that the solution

will manage.

– They describe capabilities the system will be able to perform in

terms of behaviors or operations—specific information

technology application actions or responses.

b. Non-functional Requirement

– They capture conditions that do not directly relate to the

behavior or functionality of the solution describe

environmental conditions under which the solution must remain

effective Qualities that the systems must have.

– They are also known as quality or supplementary requirements.

– These can include requirements related to capacity, speed,

security, availability and the information architecture and

presentation of the user interface.

14

1.4.4 Transition Requirements

They describe capabilities that the solution must have in order to

facilitate transition from the current state of the enterprise to a

desired future state.

They will not be needed once that transition is complete.

They are differentiated from other requirements types because:

1. They are always temporary in nature implementation project

2. They cannot be developed until both an existing and new

solution are defined

Examples: data conversion, skill gaps, etc.

Current

State

Future

State

Transition

Requirements

15

1.5 Emergent Properties

Requirements which cannot be addressed by a single component,

but which depend for their satisfaction on how all the software

components interoperate.

Examples of emergent properties:

– Reliability

– Maintainability

– Performance

– Usability

– Security

– Safety

16

1.6 Quantifiable Requirements

Software requirements should be stated as clearly and as

unambiguously as possible, and, where appropriate, quantitatively.

It is important to avoid vague and unverifiable requirements which

depend for their interpretation on subjective judgment (“the

software shall be reliable”; “the software shall be user-friendly”).

This is particularly important for nonfunctional requirements.

17

Requirements Measures

Property Measure

Speed Processed transactions/secondUser/Event response timeScreen refresh time

Size K BytesNumber of RAM chips

Ease of use Training timeNumber of help frames

Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability

Robustness Time to restart after failurePercentage of events causing failureProbability of data corruption on failure

Portability Percentage of target dependent statementsNumber of target systems

18

1.7 System Requirements &

Software Requirements

System means:

– “an interacting combination of elements to accomplish a

defined objective. These include hardware, software, firmware,

people, information, techniques, facilities, services, and other

support elements,” - as defined by the International Council on

Systems Engineering (INCOSE).

System Requirements:

– are the requirements for the system as a whole. In a system

containing software components, software requirements are

derived from system requirements.

19








20

2.1 Process Models

The objective of this topic is to provide an understanding that the

requirements process:

– is not a discrete front-end activity of the software life cycle,

but rather a process initiated at the beginning of a project and

continuing to be refined throughout the life cycle

– needs to be adapted to the organization and project context

In particular, the topic is concerned with how the activities of

elicitation, analysis, specification, and validation are configured

for different types of projects and constraints.

21

A simplified representation of a software process, presented from

a specific perspective.

Examples of process perspectives are

1. Workflow perspective - sequence of activities;

2. Data-flow perspective - information flow;

3. Role/action perspective - who does what.

22

Adaptive vs. Predictive Process Models

Agile Iterative Waterfall

Adaptive/ Change-Driven Predictive/ Plan-Driven

Waterfall: since 70’s till today;

▫ Aims to predict all aspects (requirements, risks...),

▫ The solution is accomplished at the end of the process

Iterative: since 80’s (as opposed to Waterfall) till today;

▫ The solution features are developed incrementally,

▫ Components of the solution may be ready at the complition of the first

iterations

▫ E.g: RUP, UP

Agile: since 90’s till today;

▫ Similar to Iterative, but the iteration duration is few weeks

▫ Each iteration may be managed according the waterfall approach

▫ E.g: Agile UP, Scrum, Crystal Clear, Extreme Programming, etc

23

2.2 Process Actors

The roles of the people who participate in the requirements

process.

Interdisciplinary process The requirements specialist needs to

mediate between the domain of the stakeholder and that of

software engineering.

Many people involved besides the requirements specialist, each of

whom has a stake in the software.

The stakeholders will vary across projects, but always include

users/operators and customers .

24

Examples of software stakeholders

1. Sponsor

2. Users

3. Customers Who represent the software’s target market.

4. Market analysts Market needs customers.

5. Regulators Software Compliance

6. Software engineers Profiting from reusing !!!

7. Others (Direct or Indirect!!!)

25








26

3.0 Definitions

Requirements elicitation is concerned with:

1. where software requirements come from

2. how the software engineer can collect them.

It is the first stage in building an understanding of the problem the

software is required to solve.

It is fundamentally a human activity Relationships between the

development team and the other stakeholders.

Also known as ‘requirements capture’, ‘requirements discovery’,

and ‘requirements acquisition’.

Needs good communication between users and software engineers.

Requirements specialists may mediate between the domain of the

software users (and other stakeholders) and the technical world of

the software engineer.

27

3.1 Requirements Sources

Requirements have many sources in typical software

It is essential that all potential sources be identified and evaluated

for their impact on the software.

Sources include:

1. Goals objectives of the software value vs. priority vs.

cost of goals Feasibility Study

2. Domain knowledge: The software engineer needs to acquire,

or have available, knowledge about the application domain.

+ve Interaction assess the trade-offs

3. Stakeholders ( Process Actors) identify, represent, and

manage different viewpoints/interests/agenda

28

4. The operational environment observing constraints in

real-time software interoperability constraints in an

office

5. The organizational environment support a business

process impact of the structure, culture, and internal

politics of the organization.

29

3.2 Elicitation Techniques

Requirements sources are identified eliciting requirements

techniques for getting human stakeholders to express their

requirements Difficulties

Elicitation is not a passive activity:

– Software engineers need to work hard to elicit the right

information.

Communication skills are highly needed

30

Making calls Sending SMS __ No internet used

No multimedia needed

Needs

VS.

Wants

Requirements Scope

Challenge: Needs VS. Wants

http://www.google.com/imgres?imgurl=http://www.touchtotech.com/wp-content/uploads/2009/08/Nokla_E97.jpg&imgrefurl=http://www.touchtotech.com/category/phone/brand/clone-phone/&usg=__fUlsEE0An1-sCAg244due25PdAo=&h=388&w=590&sz=33&hl=en&start=89&tbnid=XL0fjcA4xStHIM:&tbnh=89&tbnw=135&prev=/images?q=Nokia+E97+images&ndsp=18&hl=en&sa=N&start=72

http://electroschematics.com/wp-content/uploads/2008/06/nokia-3310.jpg

31

Communication – Basic Model

Encode. To translate thoughts into a language that is understood by others.

Message. The output of encoding.

Medium. The method used to convey the message.

Noise. Anything that interferes with the transmission and understanding of the message (e.g., distance).

Decode. To translate the message back into meaningful thoughts or ideas.

32

Communication Modes

33

1. Document Analysis

2. Interface Analysis

3. Prototyping

4. Observation

5. Interviews

6. Brainstorming

7. Focus Groups

8. Requirements Workshops

9. Survey/Questionnaire

Techniques

34

About Elicitation Techniques

Is this a single or multi-stakeholder environment?

o More difficult in multi-stakeholder environment

o Challenging if no consensus

o The SE role is not to make decisions about which

requirement is “right”, but to create the right conditions and

to facilitate the sessions

Are all the stakeholders located together?

Is this a well understood business environment?

Is it brand new to the Stakeholders ?

35

Different Techniques For Different Stakeholders

1. Working With Executives:

Need to be more conservative with the time they need to spend

with the project

Need to be flexible with scheduling

2. Working With The Users Of The System:

May need to spend time with them while they are performing

their work

May need to show them different scenarios in a prototype

3. When Exploring Regulatory Requirements:

Focus on exploring/reviewing existing documentation

Interviewing SMEs

36

One of the best way to prepare for upcoming events

Provides information about the As Is, no requirements about the To Be.

Source of information:

System documentation

Enhancement requests

Problem logs

User manuals

Training manuals

Product documentation

Very time consuming process, maps/SME input about how to work with the documentation is of big help

3.2.1 Document Analysis

37

Most of the systems built today will need to interface other

systems.

May not be enough to only ask the stakeholders about it, they

may be concerned with “their part of the system” only. Be

proactive and creative

Types:

1. User interface

2. External interface

3. Hardware interface

3.2.1 Interfaces Analysis

38

Dramatically reduces abstractness (unlike other techniques)

Establish realistic objectives about the prototyping scope

Establish realistic expectations, it is just a prototype

You may use 2 types of prototypes regarding how it will evolve:

1. Evolutionary – the prototype will gradually get refined and eventually becomes the final product

2. Throwaway

2 types of prototypes regarding scope:

1. Horizontal – shallow but broad – the purpose is to include the many of the functions although a high level of detail

2. Vertical – the prototype focuses on a small portion of the system, but going down into a lower level of detail.

Don’t over-engineer the prototype, you may go to a non-functional prototype.

3.2.3 Prototyping

39

3.2.4 Interviews May be self-standing technique or a part of another technique

Can be:

– Open ended – the interviewer starts with predefined questions and

continues the interview based on the input

– Close ended (a survey) interview – the entire interview is guided by

the list of questions

Look at the interview as a formal event:

– Agenda

– Objectives

– Research and prepare the interview

– List the questions

– Brief the people prior to the interview

– Send the questions ahead of time

Good to have interviewer and scripter

Either Structured or Unstructured

40

Types of Questions

Open ended (“tell me about ...”) introduce topics that the interviewer may not have been aware of.

Risks: Stakeholder may loose focus or may not be comfortable with.

Close ended (“Do you perform XYZ today?”) – they keep the interviewee focused. Many of these questions will come naturally as a result of the interview progress (active listening)

Probing questions (“What do you mean by “zero defects?”) – when there is a need to clarify/to probe something

Validating questions (“Does this flow chart correctly represent this process?”) – Stop periodically and rectify/baseline input provided during the interview

Typical sequence would be:

1. Start with open ended questions

2. Narrow down answers with close-ended

3. Clarify with probing questions

4. Get commitment with validating questions

41

Can be done

Actively (interacting with the stakeholder)

Passively (using video records or one-way mirrors)

Primary used with the end-users of the System being defined to

understand what do they do on daily basis.

Often users are not comfortable of being shadowed they may

do the work differently then they normally do it when not

observed.

You must build trust before applying this technique

It may be very time consuming

You primarly acquire knowledge about the As-Is situation

3.2.5 Observation

42

Work with group of stakeholders to discover (they are advising, not

decision makers)

Used typically to find out what features the most of the user population

is interested in

Needs good facilitation

Set expectations upfront, the participants must be aware that their

recommendations may not end up in the solution

Keep short in time frame to be effective (1-2 hours)

6-12 participants

May work with

Homogeneous group – e.g. on a process definition use flowcharting

Heterogeneous group – e.g. on a process definition use swim lanes

activity diagrams

3.2.6 Focus Group

43

Typical steps can be:

Clearly state the problem to keep focus

Define the ground rules for the session, e.g. no disagreements are allowed etc

Start the brainstorming make sure to capture all ideas, it is fine to clarify ideas, but not to question them

Run the session for a pre-determined amount of time, or until the team is running dry on ideas

Normalize the list :

1. Combine any duplicates

2. Remove ideas upon agreement

3. Cluster similar ideas

Identify conflicting ideas and make decision

Organize the findings in an easy-to-read-format

3.2.7 Brainstrorming

44

May be used with any other technique

Use the group synergy to generate a lot of ideas and then take the

maximum value out of them

Filter the good ideas at the end

During the session watch out for group dynamics, try to involve all

participants

6-8 participants

45

Facilitated Workshops

JAD = Joint Application Design/Development (IBM, 70s)

Used for capturing, documenting and modeling requirements in a

multi-stakeholder environment

Excellent to build consensus and define requirements

Requires stakeholder buy-in into the process

There must be willingness from the Sponsor to delegate authority

to the group. The group must be authorized to make decisions

(unlike focus group)

JAD session takes significant planning training, and dedication of

resources to be successful.

JAD success depends on the Group

3.2.8 Requirements Workshops

46

Workshop Roles

Facilitator – see below

SE/Analyst – to ask the right question, works closely with the

facilitator

PM – to ensure the project elements are addressed and balanced

(triple constraint)

Scribe – makes sure everything to value has been captured,

provides “double check” for consistency

Participants:

Customer

SME

The Sponsor

47

The Facilitator

To sense how the team is working

To guide the team when the team is struggling

To ensure participation by all stakeholders

The facilitator should be neutral to the outcomes of the project, should not have interest in the result

The good facilitator will be “invisible”, the bad facilitator will be noticed

Key competences:

Strong listening skills

Good speaker

Able to read people (speech and body language)

Calm

48

Good for situations where:

1. there are a large number of stakeholders

2. logistics make it difficult to get together in person.

Help the stakeholders to stay focused on the topic of discussion

Assure the quality of the answers and the return rate (quantity)

Make it short, to the point

Unlike interviews, here you can not ask probing questions

Make questions:

Not ambiguous – the stakeholder will understand them correctly

Don’t guide to ambiguous answers – you will understand them correctly

You can use a number of question types- MCQs, Rating on scale, Sequencing, Open answer etc.

3.2.9 Survey

49

Provide a scale for rating. May decide not to include middle

(“neutral”) value on the scale to encourage decision making

You will likely get not fully representative answers, typically you

will get answers from those:

Who really like you

Who really hate you

Decide on whether to keep it:

1. anonymous (with good quality answers)

2. named (with possibility to follow up if clarification is needed)

50

Technique Synonym When used

Brainstorming Earlys tages - to stimulate creative thinking for ideas generation

Gather large number of ideas (but must keep focus)

Document

Analysis

Review existing

documentation

Understand As-Is. Pre work to Customer interview and other

techniques

Technology change with old business processes

Focus Group Gather a lot of ideas without committing to implementation

Early phase of project

Interface

Analysis

External Interface

Analysis

Understand the big picture. Understand project impact

(May involve people from outside the project team)

Interviews All situations (often is a subset of other techniques)

Observation Job Shadowing Stakeholder requirements; Business analyst new to the domain;

(Requires time committment from both BA and observed)

Prototyping Storyboarding,

Navigation Flow, Paper

Prototyping, Screen

Flows

Reduce abstractness. Bridge language gaps

Do throughout requirements process (used with other techniques)

Requirements

Workshops

Elicitation Workshops,

Facilitated Workshops,

JAD session

Multi stakeholder environment;

Consensus building needed (Large undertaking, requires formal

planning)

Survey /

Questionaire

Wanting to reach a large population; Geographically disbursed

population;

Wanting consistency in interviewing (Realistic expectations on return

rates)

51








52

53

4.0 Definitions

This topic is concerned with the process of analyzing

requirements to:

1. Detect and resolve conflicts between requirements

2. Discover the bounds of the software and how it must interact

with its environment

3. Elaborate system requirements to derive software

requirements

Care must be taken to describe requirements precisely enough to

enable the requirements to be validated, their implementation to

be verified, and their costs to be estimated.

54

4.1 Requirements Classification

Requirements can be classified on a number of dimensions.

Examples include:

1. Functional or nonfunctional

2. Derived from high-level requirements or an emergent property, or

imposed directly by a stakeholder or some other source.

3. Product or process requirements

4. The requirement priority meeting the overall goals

Mandatory, Highly desirable, Desirable, or Optional Balanced

against the cost of development and implementation.

5. The scope of the requirement impact on the product

global scope strongly affect the software architecture

narrow scope offer a number of design choices .

6. Volatility/stability: estimate the likelihood of the requirement

changes impact analysis.

55

4.2 Conceptual Modeling

The development of models of a real-world problem is key to

software requirements analysis.

The purpose is to understand the problem not to design a

solution relationships & dependencies.

Several kinds of models data and control flows, state models,

event traces, user interactions, object models, data models

56

4.3 Architectural Design

At some point, the architecture of the solution must be derived.

Architectural design the requirements process overlaps with software or systems design impossible to decouple the two tasks.

In many cases, the software engineer acts as software architect the process of analyzing and elaborating the requirements demands that the components that will be responsible for satisfying the requirements be identified.

Architectural design is closely identified with conceptual modeling.

57

4.4 Requirements Negotiation

Also known as ‘conflict resolution’.

Resolving problems with requirements:

– conflicts may occur between:

• two stakeholders requiring mutually incompatible features

• requirements and resources

• functional and non-functional requirements

• Etc..

Don’t make unilateral decisions consensus on trade-offs.

For contractual reasons:

– Decisions Customer Responsibility Requirements Validation

58








59

5.0 Definitions

The term “specification” refers to the assignment of numerical

values or limits to a product’s design goals.

Typical physical systems have a small number of such values.

Typical software has a large number of requirements

Software Requirements Specification production of a document

can be reviewed, evaluated, and approved.

For complex systems, particularly those involving substantial non-

software components, as many as three different types of

documents are produced: system definition, system requirements,

and software requirements.

For simple software products, only the third of these is required.

60

5.1 The System Definition Document

This document (also known as the user requirements document or

concept of operations) records the system requirements.

It defines the high-level system requirements from the domain

perspective. Its readership includes representatives of the system

users/customers (marketing may play these roles for market-driven

software) depends on the domain area.

It lists the system requirements + background information about

the overall system objectives, its target environment, constraints,

assumptions, and non-functional requirements.

It may include conceptual models designed to illustrate the system

context, usage scenarios and the principal domain entities, as well

as data, information, and workflows.

61

5.2 System Requirements Specification

Developers of systems with substantial software and non-software

components. A modern airliner, for example, often separate the

description of system requirements from the description of

software requirements.

In this view, system requirements are specified, the software

requirements are derived from the system requirements, and then

the requirements for the software components are specified.

System requirements specification is a systems engineering

activity.

62

5.3 Software Requirements Specification

Software requirements specification establishes the basis for

agreement between customers and contractors or suppliers on

what the software product is to do, as well as what it is not to do.

For non-technical readers, the software requirements specification

document is often accompanied by a software requirements

definition document.

Software requirements are often written in natural language, but,

in software requirements specification, this may be supplemented

by formal or semi-formal descriptions.

63

IEEE/ANSI 830-1993 Standard Documentation

1. Introduction

1.1 Purpose of requirements document

1.2 Scope of the product

1.3 Definitions, acronyms and abbreviations

1.4 References

1.5 Overview of the remainder of the document

2. General description

2.1 Product perspective

2.2 Product functions

2.3 User characteristics

2.4 General constraints

2.5 Assumptions and dependencies

3. Specific requirements

– Covering functional, non-functional and interface requirements.

4. Appendices

Index

64

Writing Essentials

1. Requirements are read more often than they are written. You should invest time to write readable and understandable requirements

2. Do not assume that all readers of the requirements have the same background and use the same terminology as you

3. Allow time for review, revision and re-drafting of the requirements document

Writing Guidelines

1. Define standard templates for describing requirements

2. Use language simply consistently and concisely

3. Use diagrams appropriately

4. Supplement natural language with other description of requirements

5. Specify requirements quantitatively

65

Document Usage

System Customers

Specify requirements and read them to

check that they meet the changes. They also

specify changes to the requirements

Managers

Use the requirements documents to plan a

bid for the system and to plan the system

development process.

System Engineers Use the requirements to understand what

system is to be developed.

System Test Engineers Use the requirements documents to develop

validation tests for the system.

System Maintenance

Engineers

Use the requirements documents to

understand the system and the relationships

between them.

66








67

6.0 Definitions

Requirements validation is concerned with the process of

examining the requirements document to ensure that it defines

the right software (that is, the software that the users expect).

The requirements documents is subject to validation and

verification procedures.

Requirements are validated to ensure that:

1. The software engineer has understood the requirements

2. The requirements document conforms to company

standards, and that it is understandable, consistent, and

complete

Different stakeholders should review the documents.

Requirements documents are subject to versioning

68

Verification VS. Validation

Verifying Doing the things right

Validating Doing the right things

Verifying Methodologies are OK

Validating Objectives are OK

69

6.1 Requirements Reviews

The most common means of validation is by inspection or reviews

of the requirements documents.

Reviewers should look for errors, mistaken assumptions, lack of

clarity, and deviation from standard practice.

The composition of the group is important (at least one

representative of the customer should be included for a customer-

driven project, for example)

It may help to provide guidance on what to look for in the form of

checklists.

70

6.2 Prototyping

Is also used to validate the SE’s interpretation of the software

requirements

Advantage: they can make it easier to interpret the software

engineer’s assumptions and, where needed, give useful feedback

on why they are wrong.

– Ex: The dynamic behavior of a user interface can be better

understood through an animated prototype than through textual

description or graphical models.

Disadvantage: the danger of users’ attention being distracted from

the core underlying functionality by cosmetic issues or quality

problems with the prototype Several people recommend

prototypes which avoid software, such as flip-chart-based

mockups.

Prototypes may be costly to develop feasibility

71

6.3 Characteristics of Good Requirements

It is essential that the requirements should be Complete,

Clear, Correct, and Consistent (4 Cs).

The requirement is fully stated in one place with no missing information. Complete

The requirement is concisely stated without jargon, & acronyms (unless

defined elsewhere). It expresses objective facts, not subjective opinions.

It is subject to one and only one interpretation.

Vague subjects, adjectives, prepositions, verbs and subjective phrases are

avoided.

Negative statements and compound statements are prohibited.

Clear

If a requirement contains facts, these facts should be true. Correct

The requirement does not contradict any other requirement and is fully

consistent with all authoritative external documentation.

Consistent

72

Other Characteristics…

The requirement addresses one and only one thing. Unitary

(Cohesive)

The requirement is atomic, i.e., it does not contain conjunctions. E.g.,

"The postal code field must validate Sudanese and Egyptian postal

codes" should be written as two separate requirements:

1. The postal code field must validate Sudanese postal codes

2. The postal code field must validate Egyptian postal codes

Non-Conjugated

(Atomic)

The requirement meets all or part of a business need as stated by

stakeholders and authoritatively documented.

Traceable

The requirement has not been made obsolete by the passage of time. Current

The requirement can be implemented within the constraints of the

project.

Feasible

The implementation of the requirement can be determined through:

inspection, demonstration, test, and/or analysis.

Verifiable

73

6.4 Acceptance Tests

Software requirement is validated vs. finished product

Requirements which cannot be validated just wishes

An important task is to plan how to verify each requirement

designing acceptance tests

Identifying and designing acceptance tests may be difficult for

non-functional requirements quantitative analysis

74








75

7.0 Introduction

Activities & processes are not always linear

The requirements process spans the whole software life cycle.

Change management and the maintenance of the requirements are

key to the success of the software engineering process.

Not every organization has a culture of documenting and managing

requirements:

– It is frequent in small companies, driven by a strong “product

vision” and limited resources, to view requirements

documentation as an unnecessary overhead.

– As these companies expand, in terms of customers and products,

they discover that they need to recover the requirements that

motivated product features in order to assess the impact of

proposed changes

76

7.1. Iterative Nature of the Requirements

Process

There is general pressure in the software industry for shortening

the development cycles competition

Most projects are constrained by their environment

It is, sometimes, impractical to implement the requirements

process as a linear, deterministic process in which software

requirements are elicited from the stakeholders, base-lined,

allocated, and handed over to the software development team.

It is certainly a myth that the requirements for large software

projects are ever perfectly understood or perfectly specified.

77

7.2. Change Management

Change management is central to the management of

requirements

It describes the role of change management, the procedures

that need to be in place, and the analysis that should be

applied to proposed changes.

78

7.3 Requirements Attributes

Requirements should consist not only of a specification of what is required, but also of information which helps manage and interpret the requirements.

This should include the various classification dimensions of the requirement and the verification method or acceptance test plan.

It may also include additional information such as a summary rationale for each requirement, the source of each requirement, and a change history.

The most important requirements attribute, is an identifier which allows the requirements to be uniquely and unambiguously identified.

79

Requirement Attribute:

Requirement ID [Insert unique identifier for the Requirement, e.g. RQ_xxx_yyy; xxx - project code; yyy - progressive

number ]

Requirement [state the requirement]

Priority [Specify the relative importance of a requirement to the solution, Common scales include "critical, high,

medium, low" and "must, could, should, would" (MoSCoW method).]

Owner [The stakeholder(s) with the authority to approve a requirement. Owners help determine the priority of the

requirement, since they are responsible for the benefits the requirement will deliver if implemented. Critical for

requirements change management. The owner may or may not be the source.]

Source [The stakeholder(s) from whom the requirement was elicited. Sources may not be owners of the requirements

they provide (e.g. End Users or Customers). Critical for project change management]

Status [State the status of the requirement: “draft, reviewed, approved, rejected”. Status captures the change or

progress of the requirement within the project and across projects.]

Rationale [Captures the reason why the requirement exists. If project objectives change, the rationale helps provide an

understanding impact of the change on the requirement]

Dependency [Depicts the relationships between requirements where one is dependent on another]

Parent

requirement ID [Defines a hierarchy of requirements]

Category [A logical grouping of requirements.]

References [References to illustrating material, documents, pictures etc.]

80

7.4 Requirements Traceability

Its purpose is to create and maintain relationships between

business objectives, requirements, other team deliverables, and

solution components to support business analysis or other

activities.

Relationships

– After examining and organizing the set of requirements,

record the dependencies and relationships for each of the

requirements.

81

Types of Rraceability:

Backward Traceability Derivation

Forward Traceability Allocation

Comp_1

Comp_2

Comp_3

Comp_n

R1

R2

R3

R4

Requirements

Allocation

Derivation

System Components

82

Traceability is very important in case of:

– Change Management:

• Impact analysis is performed to assess/evaluate the

impact of a change.

• Traceability is a useful tool for performing impact

analysis.

• When a requirement changes, its relationships to other

requirements or system components can be reviewed.

Requirements Management System:

– A specialized requirements management tool is generally

needed to trace large numbers of requirements.

83

7.5 Measuring Requirements

Practically, it is useful to have some concept of the “volume” of

the requirements for the software product.

This number is useful in evaluating the “size” of a change in

requirements, in estimating the cost of a development or

maintenance task, or simply for use as the denominator in other

measurements.

Functional Size Measurement (FSM) is a technique for evaluating

the size of a body of functional requirements.

84

Requirements Volatility:

– Is a measure of how much program’s requirements change once

coding beings.

– Projects for which the requirements change greatly after coding

begins have a high volatility, while projects whose

requirements are relatively stable have a low volatility.

Requirements Volatility Index (RVI):

A = No. of requirements added

D = No. of requirements deleted

M = No. of requirements modified

Approved = No. of initial approved requirements

85

Documents

02- Software Requirements