se: chapter 4 capturing the requirements

SE: CHAPTER SE: CHAPTER 44Capturing the Capturing the RequirementsRequirementsTwo types of requirements : functional and non-functional

Eliciting requirements from customers

Types of requirements

Notations and methods for capturing requirements

Ensuring requirements quality

Documenting requirements

4.1 The Requirements Process4.1 The Requirements ProcessThe nature of new a system

The new system may replace an existing system or way of doing things

The new system is an enhancement or extension of a current manual or automatic system

Frequently the new system is planned for doing things that have never been done before

A RequirementIs a feature or a description of something the system

is capable of doing in order to fulfill the system’s purpose

The Requirements Process

The process of capturing requirementsSee Fig 4.1, p.136The process steps

First, we work with customers to elicit the requirements

By asking questions, demonstrating similar systems, or developing prototypes

Next, we capture the requirements in documentsSo that we and our customers agree on what the system

should do

Next, The requirements are re-written in a more formal or mathematical representation

So that the designer can transform the requirements into a good system design

The Requirements Process The process of capturing requirements

The process stepsNext, a verification step ensures the requirements are

complete, correct and consistentNext, a validation step makes sure that we have

described what the customer intends to see in the final product.

Requirements process is criticalSee Sidebar 4.1, p.137

The Top 8 factors that cause the failure of projectsIncomplete requirements and changing of

requirements account for 13.1% + 8.7%

Requirements Elicitation Use a variety of techniques

Examine what is already done in the old system or old ways ?

Work with users and customers to understand the problem to find a solution

Identify people, processes and resources involved and then document the relationships among them

Who and in which role people are involved in the system’s functionalities

Find out which data items are involved, where do they come from, how they are passed from one role to another, which processes transform them from one form or state to another

Ask the same question in many waysTo make sure we understand what the users and customers

want and need

Requirements Elicitation Separate the requirements into 3 categories

3 categoriesRequirements that absolutely must be metRequirements that are highly desirable but not necessaryRequirements that are possible but could be eliminated

The purposes If the system as defined will cost too much, or take too

long to developCategory 3 requirements can be droppedCategory 2 requirements can be analyzed for elimination

or postponement

Requirements Elicitation The contents of the requirements

Each of a system requirements deals with objects or entities, that states they can be, the functions that are performed to change states or object characteristics

We look for requirements that define the system objects, the limit or restriction for objects, the relationships among different or multiple objects

The criteria for an valid requirementWe can test to determine if the requirement has been met. See

Sidebar 4.2, p.139The implementation-specific descriptions are not considered as

requirements, unless they are mandated by the customer Requirements addresses the purpose of the system without regard

for its implementation Requirements identify the what of the system The design identifies the how

Requirements Elicitation See Fig 4.2, p.138, for the processThe goal of the Requirements process

Requirements are elicited at the beginning of development,

and the goal is to determine the nature of the customer’s problem

A discussion of any solution is premature until the problem is clearly defined

The form and focus of requirementsProblem and understanding is mostly easily stated in

terms of the customer’s businessAnd requirements should be focused on the customer

and the problem, not on the solution or implementation

2 Kinds of Requirements Documents 2 separate but related purposes of requirements

elicitation and analysisThe requirements should be documented in 2 formsRequirements definition : written in terms that the customer can

understand It is complete listing of everything the customer expects the

system to do It represent the common understanding of the developer and the

customer It is usually written jointly by the developer and the customer

Requirements specification : restates the requirements definition in technical terms

It is appropriate for the development of s system design It is the technical counterpart to the requirements definition It is written by the requirements analysts

Often both types of documents are neededTo make sure no information is lost or changed when

reinterpreting the definition as a specification

2 Kinds of Requirements Documents Requirements and Configuration Management

There must be a direct correspondence between each requirement definition and those of the specification

It is here that is used throughout the life cycleConfiguration Management is a set of procedures that track

The requirements that define what the system should do The design module that are generated from the requirements The code that implement the design The tests that verify the functionality of the system The documents that describe the system

Configuration management provides the threads that tie the system parts together, to coordinate the development activities

In this way, the customer’s view is tied to the developer’s view In an organized and traceable way.

Functional and Nonfunctional Requirements

Requirements describe a system’s behaviorThey cover the system and object states and the

transitions from one state to anotherObjects or entities move from one state to another

From empty to full, from busy to still, from sending to receiving, ……

In a given state, the system satisfies a set of conditions, when the system acts, it may change its overall state by changing the state of an object

To describe requirements, we think them in 2 waysFunctional, andNon-functional


Functional requirementIt describes an interaction between the system and its

environmentIt describe how the system should behave given

certain stimuliWe can use various techniques to determine the

functional requirements, including use cases, scenarios, data flow diagrams.

Use cases partition the system into a set of logical, minimally related pieces, each of which describes some way in which the system will function.

The answers to the questions addressed by functional requirements are independent of an implementation of a solution to the customer’s problem.


Non-Functional requirementIt puts restrictions on the systemIt describes a restriction on the system that limit our

choices for constructing a solution to the problem.The constraints usually narrow our selection of

language, platform, or implementation techniques or tools

However, the selection is made at the design stage, after the requirements have been specified

Both requirements are described in a formal and careful wayCustomers are not always good at describing exactly

what they want or need

Functional and Nonfunctional Requirements Customers are not always good at describing exactly

what they want or need.They know their business, but they cannot always describe

their business problems to outside.The descriptions are full of jargon and assumptions, which

we may not be familiar.

We are not always good at understanding someone else’s business concern.

We know about computer solutions, but not always about how possible solutions will affect our customer’s business activities.

We to have our jargon and assumptions, and sometimes we think we are speaking the same language when in fact we have different meanings for the same thing.

Communication between us and our customers can lead to misunderstanding or incomplete specification.

4.2 Types of Requirements4.2 Types of Requirements

Physical EnvironmentInterfacesUsers and Human FactorsFunctionalityDocumentationDataResourcesSecurityQuality Assurance

Types of Requirements Robertson suggests several sources for

requirementsSee Fig 4.3, p.144

Suggested type of requirements, existing documents, current organization and systems, stakeholder wants and needs, domain models, current situation model, re-usable requirements

Requirements can be elicited in many ways.Review the current situationApprentice with the user to understand context, problem

and relationships Interview current and potential usersMake a video to show how the new system might workDig through existing documentsBrainstorm with current and potential usersObserve structures and patterns of the customer’s problem

4.3 Characteristics of Requirements4.3 Characteristics of RequirementsRequirements can serve 3 purposes

Allow developers to explain their understandingTell designers what functionality and

characteristics the resultant system is to haveTell the test team what to demonstrate to

convince the customerTo ensure both we and the customers understand

and use the requirements properly, it is important that the requirements be of high quality.To this end, we check the requirements to make sure

they have the desired characteristics.

Characteristics of RequirementsCharacteristics of RequirementsThe desired characteristics of quality

requirementsAre the requirements correct ?

Both we and the customer should review them to assure that they stated without error.

Are the requirements Consistent ?To make sure there no conflicting or ambiguous

requirements.2 requirements are inconsistent if it is impossible to

satisfy them simultaneously.Are the requirements Complete ?

To make sure that every possible states, state changes, inputs, products, constraints and other needed things are described by some requirements.

Characteristics of RequirementsCharacteristics of RequirementsAre the requirements Realistic ?

To make sure there is no requirement which can not be done realistically.

Does each requirement describe something that is needed by the customer ?A requirement may restricts the developers

unnecessarily or includes functions that are not directly related to the problem at hand.

We should review the requirements to retain only those that work directly to solve the problem.

Are the requirements verifiable ?We must be able to write tests that demonstrate that

the requirements have been met.

Characteristics of RequirementsCharacteristics of RequirementsAre the requirements traceable ?

Can each function be traced back to a set of requirements that mandate it ?

Use this checklist to scrutinize requirementsImproving or changing them as we go.

Characteristics of RequirementsCharacteristics of RequirementsExample

“The system shall provide real-time response to queries.”Question : What “real-time response” is ?It is better written as :

“The system shall response to queries in not more than 2 seconds.”

“Accuracy shall be sufficient to support mission planning.”How can we test to see if it satisfies this

requirement ?“In identifying the position of the satellite,

position error shall be less than 50 feet along orbit, less than 30 feet off orbit.”

4.4 How to Express Requirements4.4 How to Express RequirementsRequirements definition is best performed by

working down from the top.That is to Begin by expressing the general attributes

of the system at the higher level.

Requirements specified in a natural language using normal sentences and phrases.For many years they were done just in this way.But there are several problems

How to Express RequirementsHow to Express RequirementsRequirements specified in a natural language

using normal sentences and phrases.Problems with natural language

It is unlikely that We and the customer have the same understanding of all words we use.

Natural language may not be the precise and unambiguous medium for expressing the functionality and relationship.

Requirements are not easily separated from other elements with which they deal with.

We should find ways to define requirements in a more rigorous and controlled fashion.

This approaches use formal notation to describe In this way, tools can be developed to check for

completeness and consistency, and the trace-ability

Static DescriptionsStatic DescriptionsStatic description

It lists the system entities or objects, their attributes and their relationships with each other.

It does not describe how relationships change with time This is useful and adequate when time is not a major

factor. There are several ways to describe a system statically.

Static DescriptionsStatic DescriptionsStatic description techniques

Indirect referenceA system is described with indirect reference to the problem and

its solution.That is, the properties of the solution are given without stating t

he solution method.

Recurrence relationsAn initial condition is definedAnd the transformation from one condition to the next is describ

ed in terms of the previously defined conditionExample : Fibonacci numbers

F(0) = F(1) = 1;

F(n+1) = F(n) + F(n-1)


Axiomatic DefinitionThis approach specifies the basic properties, and the behavior of

the system generates new properties from them, called theorems.This method demands a set of axioms that is both complete and

consistent; otherwise the resulting theorems will not express truths about the system.

This type of requirements definition is well-suited to the development of an expert system.

This is often used in specifying abstract data types : a set of objects and permissible operations on these objects, and axioms specify the relationships among the objects and the operations.

Expression as a languageRequirements become a specification of the syntax of the strings

Example : regular language, which can be recognized by a finite state machine


Data AbstractionIs a technique for describing what data are forWe describe data type by forming a data-type

dictionary.The central idea is to categorize data and group like

elements together.Data type or classObjects or instancesExample : student record, p.150, Fig 4.4, p.151

Data types are indicated by italicsBraces({}) indicate something that may be repeatedEnumeration : gives the possible range of valueUML notation to describe classes and their relationsClass Inheritance, Abstract method

Dynamic DescriptionsDynamic DescriptionsTechniques for Dynamic Description

These are techniques for viewing systemIn terms of changes over time

Decision TablesDescribe a system as a set of

possible conditions satisfied by the system at a given time

Rules for reacting to stimuli when certain conditions are met and actions to be taken as a result

Table 4.1, p .152Columns represent conditions or states of the system

T:True, F:False, -:dash, condition dos not matter

Dynamic DescriptionsDynamic DescriptionsDecision tables

This can generate very large tablesThe number of the states is equal to the number of

combinations of conditions, which is 2n

There may exist redundant rules which are covered by other rules

We can reduce the size and make them easier to understand

What can the table tell us about the requirements ?If every possible set of conditions results in an action,

then the requirements specification is completeAnd we can examine the table for consistency and

eliminate any conflicting cases.

Dynamic DescriptionsDynamic Descriptions Functional description and transition diagrams

We can view a system in a similar manner as a set of states where the system reacts to certain eventsThe system’s behavior is interpreted as a series of

functionsEach function represent a transition from some inputs

to outputsWe can depict this transition by drawing a diagram of

the movement of the system from one state to anotherWe draw a circle for each state in the systemAnd a directed arrow to indicate the transition

Dynamic DescriptionsDynamic Descriptions Functional description and transition diagrams

We can express each system transition as

f (Si,Ci) = Sk

Fig 4.5, p.153Other notations for depicting state transitions

Fig 4.6, p.154, fence diagramUML state transitions diagram, see Fig.4.7, p.154

Example Fig 4.8, p.155

It is important to separate expectations or assumptions from what the requirements are actually saying. See Sidebar 4.5, p.155, Fig 4.9

Dynamic DescriptionsDynamic Descriptions Event Tables

System states and transitions can be represented in an Event TableVertical axis consists of the states or sets of

conditionsAlong the Horizontal axis, we place the eventsThe cells contain the actions that take place when the

event at the top of the column occursExample : Table 4.3, p.156

Dynamic DescriptionsDynamic DescriptionsPetri Nets

The need for representing concurrencyWhen several events occur at once, sometime

a system must perform parallel processingA major problem in this case is the need to sy

nchronize eventsSeveral events may occur in parallel but are perfo

rmed in an unpredictable order.


We can extend the notion of transition to describe synchronization and parallelIn this situation, several events trigger the move from

one to another state F(StateA, Event1,…,EventN) -> StateS

In more general, once the transition is initiated, the system may moves into several states in parallel

F(StateA, Event1,…,EventN) -> State1,…,StateM

The complicating factor here is the need for coordinationThe activities are occurring in parallel, andWe need some way to control the collection of events

to change states


Petri Net is an alternative that is well suited for expressing parallel processing requirementsFig 4.10, p.158To handle the coordination of events and states, each

state is associated with a set of tokens,Fig 4.10, p.158The tokens represent events. Once it occurs, a token

may travel from one state to anotherTransitions are described by a set of firing rules

Each firing rule explains how tokens are associated with a state

When the correct number and type of tokens are present in one state, tokens are released to travel to another state


Transitions are described by a set of firing rules

Thus, the firing rules correspond to transition functions

Tokens and firing rules allows the Petri Net to represent and synchronize activities that may be taking place concurrently

When the conditions for each state are met, the tokens are ready to fire. In this way, the tokens synchronize events

After the tokens have fired, the result is the movement of tokens to the other side of the transition.

Dynamic DescriptionsDynamic DescriptionsObject-Oriented Specification

Object-Oriented is sometimes more appropriate to write requirements

Object-Oriented approach views the a system as a set of independent objects and their relationsRather than as a set of input/output transformations

Key concepts of Object-OrientedObject : encapsulation, attributes and methodsClass : objects with the same structure and interfacesClass inheritance : generalization, specializationPolymorphism : abstract methods can be defined for

more than one class of objects

Dynamic DescriptionsDynamic DescriptionsObject-Oriented Specification

Object-Oriented requirement specification3 models of OMT (Object Modeling Technology)

Object model, dynamic model, functional model

UML (Unified Modeling Language)use-case views, logical views, component views, concurren

cy views, deployment viewsOr static views, dynamic views, physical views, workflowuse-case diagram, class diagram, object diagram, state diagr

am, sequence diagram, collaboration diagram, activity diagram, component diagram, deployment diagram

See Chapter04 reference 1 on 面向对象分析与设计 UML

4.5 Additional Requirements Notati4.5 Additional Requirements Notationsons

Warnier DiagramsData flow diagramsSoftware Requirements Engineering MethodolyStructured Analysis and Design TechniqueZ

Warnier Diagrams Warnier Diagrams

Using a tree of items connected with braces({) and special symbolsbraces({) differentiate the levelsThe symbols show conditional relationships among d

ata elementsThe hierarchies are shown from left to right

See Fig 4.13 for example, p.161A Plus enclosed in a circle indicates mutually exclusi

ve relation of data itemsA solid circle indicates concatenationNumber enclosed in parentheses indicates multiple co

pies of data item

Data Flow Diagram (DFD)Data Flow Diagram (DFD) DFD is used to exhibit the requirements for the

flow of data, and the relations with functionsThis is a technique of requirements hierarchy

The hierarchies are expressed by layeringSo that different levels of detail are shown in

different layers

DFD Considers the system as a or a set of transformer of dataA diagram is used to show

the data that flow into the systemHow they are transformed, andHow they leave the system

Data Flow Diagram (DFD)Data Flow Diagram (DFD)See Fig 4.14 for symbols in DFD,

p.162 Using arrows to represent Data flows, or data path, in

and out Using ovals to represent processes or transformers

Which will process the input data and produce the output data

Using parallel bars to represent data stores, which are formatted data items that may reside in a data repository or databaseData stores usually are referred to as persistent data or

information

Using rectangles to represent actors or external entitiesThey may provide or receive data to the processes

Data Flow Diagram (DFD)Data Flow Diagram (DFD)See Fig 4.15 for example, p.162Requirements Hierarchy

DFD depicts a high-level view of the systemEach process bubble can be represented as a sepa

rate diagram to show the details of the data transformation

In this way, the requirements hierarchy is formed.

See Chapter04 reference 2 on 结构分析设计

SREMSREM SERM : Software Requirements Engineering

MethodologyTo deal with the difficulties in generating

requirements for real-time systemsSERM has 2 parts

1 for specification and 1 for analysis and reporting

Writing Requirements in RSLRSL : Requirements Specification LanguageA system is described in terms of objects and

their relationshipsRSL describes the flow of processing in terms of

what events initiate which processing

SREMSREM Writing Requirements in RSL

The flows are represented as a networkBy using both pictures and written descriptions

The network, also called R-net, specifies how a state and single input are transformed into a new state with a set of output messages

See Fig 4.16, p.163, for structure and exampleA circled plus indicate a condition or branchingA circled ampersand indicates the possible parallel

processesA triangle indicates point of synchronization

All parallel processes must be completed before the next process can begin

SREMSREM The network diagram can be translated into its

corresponding RSL statementsSee example in p.164

Other elements in SREMAlpha is a specification for the functions in an

R-netEach function includes its input, output and the

description of the transformation

Data element for definition of data structureIncluding the fields of each element, where each

element originates and a general description

SREMSREM Other elements in SERM

Validation point is a place in the diagram to denote the beginning or the end of a measurement or restriction

ASSM : Abstract System Semantic ModelThis is a database formed from the RSL statementsassisted by a set of tools, a variety of reports can be

producedSummary reportsCritical processing requirements

See Table 4.4 for the steps using SREMSYSREM adds time dimension

Allows to specify a sequence of events or concurrency

Structured Analysis and DesignStructured Analysis and Design SADT : Structured Analysis and Design

TechniqueAlso known as IDEF0 in U.S. Dept. of DefenseIt consists of 2 parts

SA : Structured Analysis, specifies the requirements using 2 types of diagrams

DT : Design Technique, explains how to interpret the results

IDEFx is a series of schemes for expressing software requirements and designsIDEF0(functional),IDEF1(data model),IDEF3(design

model), IDEF4(object-oriented), IDEF5(ontology model)

Structured Analysis and DesignStructured Analysis and Design Basic SA diagram

This is a functional diagramEach diagram represent a transformation

It consists of 4 factors : input, output, controls and mechanisms

See Fig 4.17, p.166

The diagram are arranged in a hierarchy to show more details at lower levelsNormally, each diagram consists at most 6 diagrams

at each lower level

SADT is also useful in depicting software process

Z notationZ notation Z is A Formal Specification Language

It express requirements in mathematical wayThey can be evaluated using proofs and automated te

chniques

It providesA universe of objectsAnd a set of precise rules defining objects

See Chapter04 reference 3 on Z标记语言

Z notationIt combines abstract data modeling with set theor

y and first-order predicate logicUsed to specify system states and valid state changesTools can be used to check reachable states, deadlock

s, non-determinism, and generate a finite-state machine

Some notationsMapping, partial mapping, domain substraction opera

torA Unprimed variable represent a state before an oper

ation is performed, and A primed variable represent a state after the operation performed

Z notationZ notation

Z notationZ notation Z notation

See example in p.167-168It gives the definition of operations concerning

the keyed collection

Formal specification is encouragedEspecially for the developments of safety critical

systemsThe mathematical proof technique can reveal

significant problems in the requirementsWhere they are more easily fixed than after its

implementation

Z notation

4.6 Prototyping Requirements4.6 Prototyping Requirements

Customers or users may directly be involved in the analysis and designing processesTo make sure the requirements are clear,

complete and correctCustomers know what is needed or wanted

But they are not certain whether the requirements are realistic

We should investigate options to find a feasible solution

Prototyping is a way to help us

Prototyping RequirementsPrototyping Requirements 2 approaches to prototyping

Throw-away prototypeSoftware developed to learn more about a

problem or explore the feasibility or desirability of possible solutions

It is exploratory, not intended as a part of the final product

Evolutionary prototypeSoftware developed to form the basis for part

of the final product

Prototyping RequirementsPrototyping Requirements

Prototyping is Also called rapid prototypingIt helps

To understand the requirements and decide on the final design

To select the right “look and feel” for the system’s interaction with users

Performance and efficiency must still be addressed

To “fine-tune” what the customers want and what we think will work best in a design

Non-functional requirements can also involve prototypes

See Fig 4.19,4.20,4.21, p.170

4.7 Requirements Documentation4.7 Requirements Documentation

The Necessity for Requirements DocumentationWe must keep a set of documents requirements

Not matter what method we choose for defining requirements

We and the customers will refer to them throughout developments and maintenance

Requirements DocumentationRequirements DocumentationThe level at which the requirements are

written is important too.They must be organized in such a way that

they can be tracked throughoutIllustration and diagrams should be used

to make them clear enough for idea communication, and

They be precise and consistent with the requirements text

Numbering the requirementsFor cross reference and configuration

managements

Requirements DocumentationRequirements Documentation

Problems with Requirements SpecificationSee Sidebar 4.6, p.171Uneven level of specification

Different Levels of detail, too high or too lowUse different formats or writing stylesMixed requirements with partial solutionsOver-specified requirements

When analysts identified particular types of computers and programming language, …

Under-specified requirementsFor maintenance, simulation, training, …

Requirements DocumentationRequirements Documentation

Problems with Requirements SpecificationProblem with requirements documentation

There is no universally correct level of specification

Extensive experienced customers prefer high-level, and less experienced like more detailed

RecommendationsEach clause contains only one requirementAvoid having one requirement refer anotherCollect like requirements together

Requirements Definition DocumentRequirements Definition DocumentThe contents of the document

First, outline the general purpose of the system, references to other related systems, any terms and abbreviations

Give Background and objectives of the system developmentCurrent methods and procedures in enough

detail for systems to replace an existing oneOutline Proposed new approach to solving

the problemfocus on the customer’s need, special

assumptions and the definition document

Requirements Definition DocumentRequirements Definition Document

The contents of the documentDescribe the detailed characteristics of the

proposed system, the system boundary and interfacesexplaining the system functionsA complete list of data elements and classes and their

characteristics and relationshipsinput and output to each function and performance

requirements, such as timing,accuracy and reaction to failure

The environment in which the system will operateRequirements for support, security and privacy, and

special hardware and software constrains

Requirements Specification DocumentRequirements Specification Document

The Specification covers exactly the same ground as beforeIt is written at a level appropriate for the

customer and in terms that the customer understandBut it is written from the developer’s

perspective

We establish a numbering scheme or data file for convenient trackingOften, the configuration management team

will set up or extends the scheme

Requirements Specification DocumentRequirements Specification Document

Example: the difference of 2 documentsP.173The definition is written in natural languageThe specification is written in RSL

It is clear that customers can understand the definition

documents but have difficulty with RSL

Organizations such as IEEE have standards for the content and format of the requirements documents

4.8 Participants in the Requirement4.8 Participants in the Requirements Processs Process

Many will contribute to the requirementsEach has a particular view of the system, and

how it should work, and often these view conflict

One skill of a requirements analyst is the ability to understand each view and capture the requirements in a way that reflects the concern of each participants

Participants in the Req. ProcessParticipants in the Req. ProcessParticipants can include following

Contractor monitors, who suggests milestones and schedules that constrain the development

Customers and users, who must understand the requirements so they can be sure their goal

Business managers, who must understand the likely consequences of building and using the system

Designers, who use the requirements to develop an acceptable solution that will be implemented as a software-based system

Testers, who develop test data and test suits to ensure the satisfaction of the requirements

Participants in the Req. ProcessParticipants in the Req. Process

Participants’ conflicting levelsThis can be a problemSometimes requirements should be stored in

different ways for different people to useIn addition, users and developers have

preconditions (right or wrong) about what other group people values and how they actSee Table 4.5, p.174

Good requirements analysts requires excellent “people skills” as well as solid technique skills

4.9 Requirements Validation4.9 Requirements Validation

Requirement ValidationIs the process of determining that the

specification is consistent with the requirements definition, or

Validation makes sure that the the requirements will meet the customer’s needs

Validation usually involves 2 steps1: we make sure that each specification can be

traced to a requirement definition2: we check that each requirement is traceable to

the specification

Requirements ValidationRequirements Validation

Techniques to perform the validationThe choice of the technique depends on y

our experience, preference, appropriateness for your definition and specification techniques

See Table 4.6, p.175

Validation is more than a simple check of traceabilityWe must confirm that the goal and intenti

ons of customers and users are met


Requirements reviewIs a simple way to check the requirementsIn which representatives from our staff

and the customer’s examine the requirementsRepresentatives include those who will

operate the system, prepare the input, use the output, managers of these employees, …


The Requirements review’s entailments1: Review the Stated goals and objectives

of the system2: Compare the requirements with the goal

and objectives to verify that all the requirements are necessary

3: Describe the environment in which the system is to operateBy examine the interfaces, the information

flow and structure of the system, the functions and constraints, omissions, completeness, …


The Requirements review’s entailments4: any risk is assessed and documented,

alternatives are discussed and compared, and make sure the agreement

5: talk about testing the system. How will the requirements continue to be verified and validated as development progresses.Test team, test data


When a problem is identifiedDocument it, determine its cause, and take

action to fix the problem before design begins.Example : customer may set a reliability or

availability goal that developers deem impossible to meet

Sidebar 4.7 discuss the nature and number of requirements related problems likely to find

When the validation is completedThe requirements process is completed

4.10 Measuring Requirements4.10 Measuring Requirements

Measuring requirementsInformation collected during the measuring tell

us a lot about the requirements process and its resulted requirements

The measurements usually focus on 3 areasProducts, process and resources

Measuring RequirementsMeasuring Requirements

Many ways to measuring requirementsThe number of requirements

Tell us how large the system will beIt is an estimation of the product size.It is likely that, as design and development

occur, the deeper understanding of both the problem and the solution will lead to additional requirements


The number of changes to requirementsA Large number of changes indicates some

instability or uncertainty in the problemWe should take actions to keep this number

as low as possible and practicable

Requirements size measured in typesThis allows us to learn the scope of changes

and uncertaintiesThis information permits us to take steps to

increase understanding and reduce uncertainty in particular types of requirements or parts of the problem

Measuring RequirementsMeasuring RequirementsAsk designers and testers to rate the

requirements on a scale from 1 to 5To designers, See p.178To testers, See p.178After rating the requirements

The requirements profile is determinedSee Fig 4.22, p.179Then the requirements can be passed on to the design team

if it is satisfactoryElse, the requirements process should continue until the the

rating will get better scoresThough the assessment is subjective

The general trend should be clear, and can provide useful information both to developers and the customers


We can take note for each requirementOf when it is reviewed, designed, coded,

testedThese measure tell us the progress we are

making towards the completion

Measure thoroughness of test casesWith respect to the requirement

We can also measure the number of requirements covered by each test case

4.11 Choosing a Requirement Specif4.11 Choosing a Requirement Specification Techniqueication Technique

Many more requirements techniques are availableEach one has useful characteristicsBut There is no one that is best for all projectsIt is important to have a set of criteria to

determine which is most suitable for a specific project

Example : some techniques allow the system to checked for consistency and completeness and errors

Choosing a Req. Spec. techniqueChoosing a Req. Spec. techniqueWe need a sophisticated method to handle ch

anges easilyTo see new items to add, functions to change, co

nstraint to incorporateArdis has constructed a set of criteria for eva

luating specification methodsSee p.180 : Applicability, implementability, testability, checkab

ility, maintainability, modularity, expressibility, soundness, verifiability, run-time safety, tools maturity, looseness, learning curve, technique maturity, data modeling, discipline

The importance of each property is different to different development stagesSee Table 4.7, p.181

Choosing a Req. Spec. techniqueChoosing a Req. Spec. technique

It may be better to combine several methodsSome are better at capturing non-

functional requirementsSome are better at describing data

requirementsThe choice is dependent to the needs of

both developers and customers, as well as the very characteristics of the project

4.13 , …,4.18 Are Omitted4.13 , …,4.18 Are Omitted

ExercisesExercises

On Page 192-194Problem 6Problem 7Problem 9Problem 10Problem 12Problem 15Problem 17