Requirements Satisfaction: A Tutorial in Two Parts
Jerry Conklin Part I. The Problem and Some Useful Software Development TechniquesIntroduction In thinking about what kind of paper I might write for the Oregon, IEEE BEEEP, it occurred to me that one of the most formidable problems facing software engineers is meeting the expectations of customers. This problem manifests itself most poignantly in the elicitation, specification, and implementation of requirements. In light of that fact, I decided to write about requirements satisfaction. Since you may be wondering whether there is any reason to read a paper written by me, I have attached summary curriculum vitae to help you decide. The IEEE has compiled a publication called the Software Engineering Body Of Knowledge (SWEBOK). The SWEBOK1 discusses requirements engineering under 7 headings: 1) Software Requirements Fundamentals, 2) Requirements Process, 3) Requirements Elicitation, 4) Requirements Analysis, 5) Requirements Specification, 6) Requirements Validation and, 7) Practical Considerations. Of those, the main focus herein is on Requirements Specification and Requirements Analysis. This is by no means an exhaustive and comprehensive description, even of these two areas, but is intended simply to provide a framework for the exercise proposed below. It is estimated that something like 85% of software defects are attributable to faulty requirements specification. The cost implications of this estimate are significant, especially during the maintenance life cycle. Thus, it is essential to investigate why this is so and what can be done about it. The focus of this paper is on an assumption that this requirements problem is rooted in the nature of the different language types used to specify requirements and to write source code. This paper is intended for people who enjoy programming and would like to have some fun while making a contribution to the overall body of software requirements knowledge. This discussion provides some background on the software development life cycle as it pertains to requirements specification and satisfaction, and proposes a challenge for the purpose of training and investigation. The challenge is in the form of a tutorial exercise to encourage software engineers to utilize some requirements control techniques and to gather some data on the kinds of misunderstandings that occur in attempting to give the customer what he is expecting. There is no discussion of requirements-oriented compilers or specifying requirements via software packages such as enterprise and database management since such solutions are highly stylized and do not address the general problem. As with all infrastructure methodologies, the requirements assurance techniques proposed in the following pages introduce entropy into the software development process, however; the cost/benefit ratio promises significant added value. In the following paragraphs a root problem is described briefly, some assumptions are defined, an overview is presented of a typical development strategy in moving from the requirements phase through source coding and testing, some techniques for effective requirements tracking are presented, and a tutorial challenge is proposed. Root Problem Requirements are generally specified using a Natural Language such as English. Following approval of a requirements specification, the Natural Language version of the specifications must be translated into an Artificial Language in order that they may be assembled or compiled. The result of assembly and compilation is a module containing machine instructions that one hopes will evoke operations that fulfill the needs that the user had in mind when the project was envisioned. Contrasting four characteristics of the language types (Natural vs. Artificial) may highlight the crux of the translation problem (see Figure 1.).
Figure 1. Four Language Characteristics AssumptionAn assumption is made herein that the English language requirements specification presented is if not flawless, at least, a pretty good, and typical, statement of what the program under development is supposed to do (some room for interpretation has been left intentionally). Thus, the problem focus is on the translation of requirements from English to an Artificial Language. Another assumption is that the reader does not necessarily have access to computer-aided software engineering (CASE) packages. Typical Development Strategy Typically the translation under discussion is performed in two stages; first the Natural Language requirements are translated into a design of some kind; flowchart, high-order pseudo-language, or other. The design document provides a focused summary and structured logic flow that reduces source coding to filling in the details. Thus, a good design document shows all significant decision points and eliminates verbiage whose only function is to satisfy Natural Language syntactic, grammatical rules. Source code may then be written by reference to the design document and the requirements specification from which it was produced. The translation process engaged in by the programmer requires that he bring the English language descriptions of the requirements to a sharp focus such that ambiguity is filtered out without losing relevant content. Requirements Tracking To assure requirements satisfaction in a delivered system some means must be employed to track requirement through the development life cycle. A requirements tracking matrix (RTM) is often used for this purpose (see Figure 2. RTM). To facilitate this process, a unique ID is assigned to each requirement (ReqID) as shown in Figure 2. RTM.
Figure 2. RTM In addition to the RTM, it is useful to track each requirement in the design, source code, (see Figure 5. Example Design Flowchart and Figure 3. Example of Source Code Req ID Bracketing) test plan and, discrepancy report (see Figure 4. Example Discrepancy Report)documents by associating each block, function and, symbol, as appropriate, with the requirement to which it pertains. This has the effect of assuring that every requirement is addressed in every phase of the development life cycle from requirements through delivery. It also integrates each of the phases in question by providing an explicit, cross-reference between documents (see Figure 4. Phase Document Cross-Reference Overview) such that they are conceptually bound together in a single, unified structure. [As an aside, I would suggest that you structure and sequence the source code such that it reflects the structure and sequence of the operations evoked by the generated machine code.]
Figure 3. Example of Source Code Req ID Bracketing
Figure 4. Example Discrepancy Report  Figure 4. Phase Document Cross-Reference Overview The ReqID provides explicit cross-referencing between all the cited documents. The tracking provided by the techniques described in the preceding paragraphs provides some assurance that: a) All requirements have been addressed and, b) No code has been produced for which there is no requirement. Link to Part II | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Send comments about this site to Oregon Section Webmaster | KAVI® where .orgs workSM