REQUIREMENTS ANALYSIS & SPECIFICATION

DRAFT DUE: October 12 / 13 (three copies)

FINAL DUE: October 26 / 27 (two copies)

Your team is to write a requirements analysis and specification for the problem you have been assigned. Since the problem statement you've been given is ambiguous, you must use your imagination. Ask anyone you choose to provide background information and ideas, consult the WWW, fill in the gaps in the problem concept, and select relevant features to lead to a realistic requirements analysis and specification. Above all, since this is the first stage of the design, be "user-oriented." Be creative in detailing the features specified, in formulating further features, and in providing motivation for all features. Realism from the point of view of the software developer is expected, also.

It is often very helpful to consult a client or potential clients. You may ask someone outside your team to be a surrogate client. If you want help identifying and meeting a potential client or consultant, ask your instructor. (You may also contact a surrogate client as well via rogere@rpi.edu.) Clients should respond with relevant answers in a consistent manner, but in general clients cannot be completely counted upon for such ideal answers. You will have to judge the relevance and usefulness of their advice and expectations. You should ask for clarification whenever a reply is not clear.

Your report will have both analysis and specification portions. The requirements analysis portion will include description and UML modeling of the application domain. The requirements specification portion will detail the features of the proposed system that are visible or important to the client. Include realistic constraints and goals in your specification. Use imagination to make it ambitious and interesting.

HINTS FOR REQUIREMENTS

• Do not blindly follow an outline of a requirements document. If you consult an outline, think about how well it fits your needs. If it seems unnatural, then the fault is probably in the outline.

• Use abstraction to lump together users having common reasons for using the proposed system. Lump together roles and functions that are similar. Explain the abstractions and then take advantage of them in modeling your clientıs current situation and in describing system goals, functional requirements and constraints.

• Don't hesitate to include new, interesting features. Get feedback from your client.

• Avoid imposing policy decisions through software design. Let the client have the freedom to set and alter policies.

• Think in general terms about the components the user interface(s) might have: timely presentation of information, queries, etc. as well as the sequences in which they are apt to be used.

• If appropriate, include appendices which help illustrate client concerns or situations, or which add detail relevant to requirements.

• Above all, this document is not to describe the software solution, but is to describe what the software must do for the client, and certainly not how the software might do the job internally.

• Review the course website material on Requirements.