A software system is characterized based on its behavior, which must be engi-neered to suit the needs of the client and end user. As we discussed in the previous chapter, these needs are known as requirements, and are initially gathered during the requirements elicitation phase of the software life cycle. In the last section, we introduced the concept of requirements analysis, whereby those requirements
gathered during the elicitation phase are evaluated, modified, and refined in order to extend the work done during requirements elicitation into a complete, accurate, and unambiguous description of the software system. At the end of the analysis phase, a final requirements specification or requirements specification state-ment is formed into the specification document, a document that formally expresses all of the requirements that make up the system (Stiller and LeBlanc 2002).
After the system’s requirements specification has been thoroughly generated, the specification document serves as the basis for the next phase in the software life cycle: system design. In order to serve this purpose, the document must be of sufficient detail to enable engineers to draw up the design (Schach2008). Analysts must use great care when working toward this level of detail as any errors, ambiguities or omissions that are not corrected during analysis, before the final-ization of the document, will be written into the design. Mistakes that are not caught will have to be corrected later in the development process, and at a much higher cost.
In addition to providing the primary resource for system design, the specifi-cation document also serves as a contract between the client and the developer.
Analysts must therefore balance the engineers’ need for detail with the client’s need for a sufficiently understandable (non-technical) description of the product being developed. After all, the specification document provides a picture of the system that will be developed, and the client is not likely to elect to continue development if they are unable to comprehend, and thus agree to, the proposed system itself. To this end, the document will contain a set of acceptance criteria.
These criteria constitute tests that have been agreed upon by both the client and developer which will be carried out during development and upon product com-pletion in order to verify that the final product meets the stated needs of the client (Schach 2008). These tests will cover both the capabilities of the system (func-tional requirements) as well as the system’s ability to operate within the necessary constraints (non-functional requirements). When the acceptance criteria are suc-cessfully met, the development team has sucsuc-cessfully finished its job.
The analysis phase presents an important challenge for a software development team. Analysts must constantly consider the different, and often contradictory, goals of their task. Producing a final specification document that meets the needs of both the engineers and the client is critical to the successful completion of a software engineering project. The rest of this chapter discusses practices and techniques designed to meet this end.
6.2.1 Evaluating Requirements Specification
The requirements specification produced during the requirements elicitation phase will not be sufficiently accurate, complete, and unambiguous to correctly describe the software system being developed. To assume otherwise would be a costly
106 6 Object-Oriented Analysis
mistake that could entirely derail a project and ruin the reputation of a software engineering firm. Instead, analysts must continue to engage the client and the end user in order to highlight incomplete or incorrect information, and then must use this information to evaluate the requirements specification. During this evaluation, analysts must keep in mind that analysis serves two distinct purposes based on two distinct groups, the client and the engineers, and that each group will view the specification from a different point of view. The vocabulary and technical infor-mation included in the specification document must thus meet the needs of both without exceeding the comprehension of either. In addition, assumptions about information made by one group cannot be assumed to be understood by the other.
To ensure that such mistakes do not occur, in depth discussions concerning the specification should be conducted amongst all of the parties involved in devel-opment (Stiller and LeBlanc 2002). Keeping in mind the issues of accuracy, completeness and ambiguity, analysts must read over the requirements in order to formulate questions about the system, which will provide the basis for these dis-cussions. These questions often come in two major forms. The first expressly covers the information provided in the existing requirements. Is it accurate? Is it complete? Is it unambiguous? The second questions, which are much harder to compose, seek to uncover information that was left out of the original specification entirely. Often times, experts may consider some piece of information to be too obvious to include at all, or too simple to require specifying. Unfortunately, such omissions may represent critical gaps in the system’s specification and may result in the reduced functionality of the final system, which may no longer meet the client’s requirements. To ensure that all necessary information is included in the final requirements specification, the evaluation must be exhaustive and in depth. It is far better to provide too much information, which can be refined before the finalization of the specification document, than to provide too little.
6.2.2 Refining Requirements Specification through Prototyping
True to its object-oriented roots, the requirements analysis is an iterative process, creating a more complete, accurate, and unambiguous specification document with each cycle. At the beginning of the phase, analysts evaluate the requirements specification for errors. This information is then added to the specification to create an updated set of requirements. This updated set is then evaluated again, and the information gained from that second evaluation is used to create an even more refined version of the set. This sequence is repeated and improved upon until the requirements specification meets the needs of the project. With each iteration, the questions produced during the evaluation should better target the needs of the analysts, and, as such, the discussions that are held should be more efficient and more focused. The process should refine not only the requirements themselves, but the communication that takes place.
A popular method for producing this desired refinement is to create a mock up of the system based on the existing requirements, which will be used to evaluate its effectiveness and to identify its weaknesses. This mock up, known as a prototype, is essentially a scaled down version of the software system, produced with limited functionality. When working to create the prototype, certain problems, such as ambiguities and outright errors will become apparent as they hinder the creation process. Evaluating the prototype is achieved by allowing users to interact with the system and recording the experience. This method allows users to provide actual feedback about the system’s functionality, and is easier to gauge than a vague discussion about intangible system characteristics (Stiller and LeBlanc2002).
6.2.3 Verifying Requirements Specification
All requirements should be verifiable. The most common method is by test. If this is not the case, another verification method should be used instead (e.g. analysis, demonstration, inspection, or review of design). Certain requirements, by their very structure, are not verifiable. These include requirements that say the system shall never or always exhibit a particular property. Proper testing of these requirements would require an infinite testing cycle. Such requirements must be rewritten to be verifiable. As stated above all requirements must be verifiable.
Non-functional requirements, which are unverifiable at the software level, must still be kept as a documentation of customer intent; however, they may be traced to process requirements that are determined to be a practical way of meeting them.
For example, a non-functional requirement to be free from backdoors may be satisfied by replacing it with a process requirement to use pair programming. Other non-functional requirements will trace to other system components and be verified at that level. For example, system reliability is often verified by analysis at the system level. Avionics software, with its complicated safety requirements, must follow the DO-178B development process.
Verifiability is necessary for a requirement, but there are other important issues as well. A requirement can be verifiable yet incorrect; and assessing verifiability alone will not detect incorrect requirements. Moreover, verification is totally irrelevant with regard to a requirement which has been overlooked. Mere analysis, inspection, or review alone will find some of these issues but, generally, is far weaker than usually is realized.
Only through effective communication between the client and the developers can a system be accurately defined, and only with this clear definition can a project hope to be successful. This process begins with the understanding of problems and of technical solutions. Then the team leaders and members who did not talk to the developer need to understand what was learned through team conversations.
Finally, organizational functions such as design, engineering, marketing, docu-mentation, testing, and customers must also understand the problem, and agree/
correlate to the technical solution. Customer-centered techniques necessitate
108 6 Object-Oriented Analysis
face-to-face communication, continuous, synchronous team work in design meetings, shared decision-making, and consensus (Holtzblatt and Beyer1995).
• Involvement and Control: Requirements can only be effectively defined when all members of the development process are involved. No one likes to feel out of control of their time, their work activities or their goals. Team members don’t want their activities dictated to them. Team members really owns their process and have skills to solve particular problem. A successful requirements process includes effective ways to foster partnership between customer and designer and team members. It must reveal the ownership of the activities of the design by customers and team members (Holtzblatt and Beyer 1995).
• Client-Developer Links: A software project is built of techniques or channels that allow customers and developers to exchange information. We refer to these as links. A wide variety of links are available to software developers. The tremendous variety of links that are available today represents both opportunity and a challenge for software development managers. Opportunity is easier to obtain inputs from clients and challenge is deciding on the type of links. By focusing on links we are able to draw insights on degree of participation that should be used to engage customers in development process. Keil and Carmel lay out three basic guidelines regarding these links: the more links the better;
avoid indirect links; and always be sure to consider links that may be considered non-traditional for the environment (Keil and Carmel1995).