Requirements Phase - CSUN

Ch10 Copyright © 2004 by Eugean Hacopians

1

Requirements Phase

• Chance of a product being on time and within budget is very slim unless the development team knows what the product should do

• To achieve this level the development team must analyze the needs of the client as precisely as possible


2

Requirements Phase

• After a clear picture of the problem the development teams can answer the question:– What should the product do?

• The process of answering this question lies within the requirements phase


3

Requirements Phase

• Common misconceptions are:– During requirement phase the developer must

determine what the client wants– The client can be unclear as to what they want– The client may not be able to communicate what

they want to the developer• Most clients do not understand the software development

process


4

Requirements Elicitation• This process is finding out a client’s

requirements• Members of the requirements team must be

familiar with the application domain• Requirement analysis is the process of:

– Understanding the initial requirements– Refining requirements – Extending requirements


5

Requirements Elicitation

• This process starts with several members of the requirements analysis team meeting with several members of the client’s team

• It is essential to use the correct terminology or settle on an agreed set– Misunderstanding terminology can result in a faulty

product – This could result in a lawsuit


6


• To solve the terminology problem:– Build a glossary of terms with initial entries– Update the glossary as the process continues– Reduces confusion between clients and developers– Reduces misunderstanding between members of the

development team• Not all development team members may be present at the

meeting


7


• Two types of interviews:– Structured

• Questions are planned, structured, and close-ended• These type of questions will give concrete answers to the

requirement analysis team

– Unstructured• Questions are open-ended• These type of questions will encourage the client to speak

out


8


• Conducting interviews are not an easy task• Interviewer must be familiar with application domain• Interviewer must approach each interview with intention

of listening very carefully to the client while suppressing any preconceived opinion about client company or needs

• There is no need to continue with interviews if requirement analysis team understands the client’s needs

• A written report must be prepared after each interview• Give a copy of the report to the interviewee

– This will allow the person to clarify any misunderstanding


9


• Scenarios are another technique to elicit requirements

• A scenario is a way the user will utilize the product– Describes what happens when an action is taken

• Enter a value• Report generation


10


• Scenario Types– Expected sequence

• What should happen if a correct value is entered

– Exception sequence• What should happen if an erroneous value is entered


11


• Scenarios must include– Start state– Expected sequence of events– Exceptions to the expected sequence of events– Finishing state


12


• Scenarios are useful in many ways– Can determine the behavior of the product– Easily understood by users– Using scenarios will insure client and user

participation in the requirements analysis phase – Scenarios (Use cases) play an important role in

Object-Oriented paradigm


13


• Other methods of eliciting requirements:– Send a questionnaire to users– Understanding how the client conducts business is a

very helpful tool in determining the client’s needs• Examine forms used by client• Examine operational procedures• Observe users in person or by videotape (with prior

written permission of those being observed)– This could backfire as a invasion of privacy


14


• It is very important to have full cooperation of all employees

• It could be extremely difficult to obtain information if people feel threatened or harassed by the process


15

Requirements Analysis• Requirement team has a preliminary set of

requirements• Requirement types:

– Functional• Specify functionality of the software

– Nonfunctional• Specify property of the software

– Reliability– Maintainability– Software runtime environment


16

Requirements Analysis

• Software must be traceable– Number each requirement– SQA team can check each requirement during

testing specification, design, implementation, and integration


17

Requirements Analysis• After preliminary analysis, the requirements document

is given back to clients• The client:

– Check for completeness• Check with individuals interviewed

– Get client priority• Client must prioritize each requirement

– Essential– Highly desirable– Desirable

• Further refine the preliminary requirements document


18

Rapid Prototyping• Software exhibits key requirements functionality• The key point is RAPID

– Build a prototype fast• The sooner, the better

– OK if crashes every few minutes

• Not included in a prototype– Error checking routines– File updating routines– Complex computations


19

Rapid Prototyping• The key is to generate a tool that clients and

developers can agree upon as quickly as possible– WHAT THE PRODUCT MUST DO– Users experiment with the prototype while developers watch– Users tell the developers how they feel about the prototype– Prototype is built for change

• Developers can change the prototype until both sides are satisfied

• The final prototype is used as basis for the specification phase


20

Rapid Prototyping• Decide which language to use for prototyping

– Use a language that a prototype can be• Build rapidly• Change rapidly

– Preferably use another language than the one intended for the final product

• Use scripts for engine• Use TKL/TK (scripting language for GUI) to build the GUI• Use HTML

– OK if slow– OK if not perfect– Most important

• Give users a tool to express themselves


21

Human Factor• Experiment with human-computer interface (HCI)

– Allows users to interact with the interface of the product– Helps development of user friendly interfaces

• Ease of use• If product is not easy to use

– Users will get frustrated– Users will not use the product

• Can reduce learning time• Lower error rate


22

Rapid Prototype as a SpecificationTechnique

• Two different approaches– First

• Use rapid prototype to write specification document• Discard prototype after specification

– Second• Modify prototype to generate the final product• Do away with specification phase• Drawbacks

– A rapid prototype can not stand as a legal document if there is a disagreement between the clients and developers

– Potential problems with maintenance due to lack of specificationdocument


23

Reusing The Rapid Prototype

• It may seem cheaper to reuse a prototype• It is unwise to reuse a rapid prototype

– It is made in a hurry– It is not carefully designed– It is not carefully implemented– May have performance issues– May lack documentation for maintenance


24

Management Implications of theRapid Prototype Model

• Challenge of explaining the concept of prototype to client – Important to discuss the issue of prototyping with

clients• It is very easy to change the prototype• Prototype is not operations-quality software• The operations-quality software can not be changed as

quickly


25

Testing During Requirements Phase

• SQA must ensure– The relevant individuals have the opportunity to

• View requirements document• Experiment with the prototype

– The requirements are traceable• Number each requirement statement


26

CASE Tools for the Requirementsphase

• Interpreted languages are good tools for rapid prototypes– No need to compile– Can be changed while demonstrating

• Draw backs of interpreted languages which do not affect rapid prototyping– Poor performance– Difficult to maintain


27

CASE Tools for the Requirementphase

• There are CASE tools that can be used for rapid prototyping– HTML builder– 4GL

• Oracle• Power builder• DB2

– JAVA tools such as Together J


28

Metrics for the Requirements Phase

• Need metrics to keep track changes:– How quickly requirements change during

requirements phase– Number of requirements changes during the

subsequent phases


29

Metrics for the Requirements Phase

• During rapid prototyping track Number of times a feature is exercised– Developers must ask for justification for

• Exercising a feature many times• Exercising a feature few times• Not exercising features

– The features exercised more often may be very important

• Design those features to urn faster


30

Object-Oriented Requirements?• There is no such thing as Object-Oriented

requirements– Similarly there is no Object-Oriented or classical

user manual• The key point of requirements phase is to

determine the client's needs• Requirements phase has nothing to do with the

development paradigm

Requirements Phase - CSUN

Documents