Requirements Analysis Techniques 12 June, 2000 Requirements Analysis Techniques Structured interviews: ask close-ended questions How fast a response time is required? Unstructured interviews: ask open-ended questions Why the current product is unsatisfactory? Questionnaire Examine the various “forms” used by the client Examine documents: operation procedures, job descriptions Set up video cameras in the workplace to record exactly what is being done Scenarios: a possible way a user can utilize the target product to accomplish some objective

Scenarios (use cases) Scenario representation Advantages of scenarios A list of (user) actions Storyboard (paper scenario) A series of sheets of paper each depicting the relevant screens and the user’s response Advantages of scenarios Demonstrate the behavior of the product in a way that is comprehensible to the user The client and the users play an active role throughout the requirements analysis process Play an important role in object-oriented analysis

Rapid Prototyping 1 A rapid prototype is hastily built software that exhibits the key functionality of the target product Client and intended end-users Describe how the rapid prototype satisfies their needs Identify areas that need improvement Developers Watch and take notes Revise the prototype

Rapid Prototyping 2 Important aspects of rapid prototyping Enable the client and the developers to agree as quickly as possible on what the product is to do The rapid prototype must be built for change Can a given language be used to produce a rapid prototype Can the rapid prototype be changed quickly? Fourth-generation languages (4GL) and interpreted languages (Recommendation from some projects carried out by IBM indicates it is very important to build a rapid prototype as earlier as possible in the object-oriented life cycle.) Rapid prototyping is particularly effective when developing the user interface to a product

Human Factors Human factors Human-Computer interface (HCI) User friendliness: the ease with which human beings can communicate with the software product easy to learn no confusion in using the product comfortable in using the product Menu-driven; Graphics (windows, icons, pull-down menus) Design different sets of HCI for different users with different skill levels and computer knowledge Provide an uniform HCI appearance across a product or groups of products

Rapid Prototyping as a Specification Technique Figure 9.2 Throwaway prototyping: The rapid prototype is used solely as a means to determine the client’s needs accurately and is discarded after the client signs off on the specifications Strengths Speed: no time is wasted drawing up written specifications Accuracy: ambiguities, omissions, and contradictions cannot arise (better rephrased as “less likely to arise”) All that needs to be done is to state the product will do what the rapid prototype does and to list any additional features that the product must support Drawbacks It is unlikely that a rapid prototype will stand as a legal statement of a contract between developer and client Potential problems with maintenance (no specifications)

Reusing The Rapid Prototype 1 Evolutionary prototyping: develop and refine the rapid prototype until it becomes the product Figure 9.3 Strength: Fast development Weaknesses Changes made to the product are expensive (similar to the build-and-fix model). Maintenance (perform on the source code) is difficult without proper specifications and design documents Performance issues are not considered up front (in the case of designing real-time systems) One way to avoid reusing the rapid prototype is to use different languages; For example, use hypertext for prototyping and C++ for production development

Reusing The Rapid Prototype 1 Ok to reuse portion of the rapid prototype (computer-generated) Component-based software development (reuse) Pass the quality assurance tests as other software component Components that are of sufficient high quality to pass design and code inspection are not usually found in a rapid prototype design documents are not part of classical rapid prototype

Other Uses of Rapid Prototyping Arriving at consensus where there is disagreement as to the client’s requirements

Management Implications of the Rapid Prototyping Model Rapid prototyping lead to client’s misconception Changes to the product can be implemented as rapidly as were changes to the rapid prototype It seems that most of the functionality is implemented in the prototype, why do you need so long to finish it? Prototyping v.s. specifying [Boehm, Gray, and Seewaldt, 1984] Performance is roughly equivalent The P versions contained less code and required less effort Therefore, the P versions have fewer functionality and are less reliable The P versions are easy to use and easy to learn Academic study; maintenance is not studied Boehm found that P version products are harder to integrate than specified. (Implication)

Management Implications of the Rapid Prototyping Model Two aspects of rapid prototyping must be taken into account by any software manager: it is short sighted to turn a rapid prototype into the final product Under some circumstances, Rapid Prototype can take the place of specification, but never replace design phase. (why?) Managing the rapid prototyping model requires a major change in outlook for a manager who is accustomed to managing only the waterfall model The increased interaction between the client and the developers

Experiences with Rapid Prototyping 1 Rapid prototyping is a viable technique that can lead to successful software development (if properly used) Reported successful case studies [Gordon and Bieman, 1995] Improved ease of use (17 case studies; none of the other 22 case studies reported hard to use. Totally 39 cases has been analyzed) Active user participation early in the software process Meets client needs Choice of language is not of critical important Final product size: four reported a decreased product size; one reported an increased product size Product features: many reported a decreased number of features; two reported an increased number of features Retaining the P part is important for large scale products, 7 among 39 are large products and all of them recommended retaining all or part of the rapid prototype. Further research needs to be done in this aspect.

Experiences with Rapid Prototyping 2 Risks (evolutionary prototyping) Badly designed product Hard to maintain Poor performance Risks grow in proportion to the size of the product