The members of a software development team must have a clear understanding of what the software product must do.
The first step is to perform a thorough analysis of the client’s current situation, careful to define the situation as precisely as possible.
This analysis may require examination of a current manual system being operated, or may need an appraisal of some computerized system to be performed. Once a clear picture of the current situation is obtained, then the question of “What must the new product be able to do?” may be answered.
During the requirements phase the developer must :-
Requirements analysis begins with the requirements team meeting with members of the client organization. The initial meeting may be used to plan subsequent interviews or techniques for soliciting the relevant information from the client’s organization.
Several techniques can be employed to elicit requirements:
Both the structured and unstructured interview may be planned. In the case of the structured interview a list of specific closed ended questions are posed and the answers recorded. E.g. “How long does it take to perform activity X” or “How many people are in the marketing dept?” or “How much was spent on the current system last month?”
- These type of targeted questions seek information the interviewer deems relevant in finding the true needs of the client.
In the case of the unstructured interview open-ended questions are asked which allow the interviewee to outline broad areas or express views/opinions/convictions that may be hard to quantify. E.g. “Explain why the current product is unsatisfactory?” or “What are the best features of the current system?” or “What would be the most effective way to accomplish task X?”
At the end of the interview process the interviewer prepares a written report outlining the results of the interview. Those interviewed should be given copies and allowed to add/clarify statements made.
A well-structured questionnaire is a useful tool for gathering information. In the case of large departments/organizations it may be impractical to conduct numerous interviews. Unlike the interview process that is interactive in nature, there is no way to pose new questions (follow-ups) based on the answers given to previous questions. This means a skilful and methodical interviewer will obtain better information than that obtained using a well-developed and well-worded questionnaire.
Another way to obtain information about a client’s operations is to examine the forms that are currently used. E.g. A purchase order may carry fields such as stock no., product code, quantity, etc. which shed light on the work flow in the organization.
Other documents such as job descriptions, internal reports, operating procedures etc. can also be very helpful.
Use of video cameras can be used to monitor what actually happens on the job in the office environment. The presence of cameras in the workplace may represent a privacy issue so careful consideration of all factors and the risks involved should be taken before embarking on this path. Legal issues may also be involved.
A scenario is a possible way in which a user can utilize the target product to accomplish some specific objective.
The developer may give a scenario of what output will be given by the product-to-be for a given input. The client representative then indicates what modifications will be needed for the scenario to correspond to what happens in practice.
Scenarios attempt to illustrate the behaviour of a future product in a way that the user can easily understand. This can result in new requirements being discovered by the developer.
A rapid prototype can be built to exhibit key functionality of the product-to-be. The client/users then will experiment with the prototype. The development team watches the experimentation and makes notes. Users can also indicate where they feel changes are necessary. The rapid prototype is changed several times until both developers and users are satisfied that the rapid prototype currently embodies the key needs of the clients.
The rapid prototype then becomes a basis for creating the specifications document.
* Key Point – Rapid prototype must be built quickly and be capable of easy on-the-spot modification. This means being written in a 4GL or interpreted language (Such as Prolog, lisp, or java)
If a rapid prototype is built then the SQA group must ensure that the relevant persons from the client organization have the opportunities to interact with the rapid prototype. All suggestions should be channeled to representatives of the client. E.g. manager responsible for analyzing user suggestions.
Interpreted languages make good sense for building rapid prototypes as there is no lengthy compilation/linking process. Additionally small changes can be made “on-the-spot” with the client and the results seen immediately. Note that interpreted code tends to be less efficient than compiled code, however great efficiencies does not matter much for a rapid prototype.
Example interpreted languages are Smalltalk, lisp, prolog, java, perl and the UNIX shell programming language. Hypertext is also gaining in popularity (E.g. HTML). Alternatively to an interpreted language a 4GL such as Oracle, Powerbuilder or SQL may be used.
CASE tools with a particular built-in rapid prototyping language may be used to gain efficiency, however the high costs of such a CASE environment may not be justifiable if it is bought solely for use with the rapid prototype.
A useful metric to be tracked during requirements analysis is how much the requirements change during this phase. The rate at which a convergence on the ”actual requirements” occurs gives management a handle on this phase. E.g. The number of changes should decrease over time as the “actual requirements” become clearer.
- How often requirements change during the rest of the development process is also a good measure of how effective the requirements team is.
- The number of times a particular feature is tried/examined by a client in the prototype is also a measure. If screen Q is accessed by every user at least once but screen T is never accessed by anyone this suggests that more information is needed on these two screens. In the case of screen Q, since this screen seems so heavily used and important, it may make sense to include special optimizations in relation to how it functions. On the other hand screen T may have to be discarded i.e. If no one ever uses it, why include it?
|
Copyright
© Adrian Als &
Charles Greenidge, 2003 |