1. 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

2. 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

3. 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

4. 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

5. 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

6. 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)

7. 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

8. 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

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

10. 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)

11. 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

12. 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.

13. 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