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

• 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

• 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

Ch10 Copyright © 2004 by Eugean 3 Hacopians 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

• 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

• 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

• 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

• 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

• 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

• Scenario Types – Expected sequence • What should happen if a correct value is entered – Exception sequence • What should happen if an erroneous value is entered

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

• 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

• 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

• 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

• 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

• Software must be traceable – Number each requirement – SQA team can check each requirement during testing specification, design, implementation, and integration

• 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

• 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

• 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

• 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

• 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

Ch10 Copyright © 2004 by Eugean 21 Hacopians Rapid Prototype as a Specification Technique • 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 specification document

• 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

Ch10 Copyright © 2004 by Eugean 23 Hacopians Management Implications of the Rapid 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

• 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

Ch10 Copyright © 2004 by Eugean 25 Hacopians CASE Tools for the Requirements phase • 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

Ch10 Copyright © 2004 by Eugean 26 Hacopians CASE Tools for the Requirement phase • There are CASE tools that can be used for rapid prototyping – HTML builder – 4GL • Oracle • Power builder • DB2 – JAVA tools such as Together J

• Need metrics to keep track changes: – How quickly requirements change during requirements phase – Number of requirements changes during the subsequent phases

• 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

Ch10 Copyright © 2004 by Eugean 29 Hacopians 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