Download Requirements Analysis: Evaluation and Synthesis and more Study notes Software Project Management in PDF only on Docsity!
LECTURE # 14
2. Software Development Fundamentals
Technical Fundamentals
2.11 Requirements Management
Requirements Analysis
Evaluation and Synthesis
Upon evaluating current problems and desired information (input and output), the analyst begins to synthesize one or more solutions. To begin, the data objects processing functions and behavior of the system are defined in detail. Once this information has been established, basic architectures for implementation are considered.
A client/server approach would seem to be appropriate, but does the software to support this architecture fall within the scope outlined in the Software Plan? A database management system would seem to be required, but is user/customer's need for associativity justified? The process of evaluation and synthesis continues until both analyst and customer feel confident that software can be adequately specified for subsequent development steps.
Throughout evaluation and solution synthesis, the analyst's primary focus is on "what, not "how." What data does the system produce and consume what functions the system must perform. What behaviors do the system exhibit, what interfaces, are defined and what constraints apply?
Models
During the evaluation and solution synthesis activity, the analyst creates models of the system in an effort to better understand data and control flow, functional processing, operational behavior, and information content. The model serves as a foundation for software design and as the basis for the creation of specifications for the Software.
Specification
docsity.com
During the evaluation and solution synthesis activity, the analyst creates models of the system in an effort to better understand data and control flow, functional processing, operational behavior, and information content. The model serves as a foundation for software design and as the basis for the creation of specifications for the Software. The customer may be unsure of precisely what is required. The developer may be unsure that a specific approach will properly accomplish function and performance. For these, and many other reasons, an alternative approach to requirements analysis, called Prototyping, may be conducted.
Concerns for Review
The customer may be unsure of precisely what is required. The developer may be unsure that a specific approach will properly accomplish function and performance. For these, and many other reasons, an alternative approach to requirements analysis, called Prototyping, may be conducted.
For example, an inventory control system is required for a major supplier of auto parts. The analyst finds that problems with the current manual system include:
(1) Inability to obtain the status of a component rapidly, (2) Two- or three-day turn- around to update a card file, (3) Multiple reorders to the same vendor because there is no way to associate vendors with components, and so forth.
Once problems have been identified, the analyst determines what information is to be produced by the new system and what data will be provided to the system. For instance, customer desires a daily report that indicates what parts have been taken from inventory and how many similar parts remain. The customer indicates that inventory clerks will log the identification number of each part as it leaves the inventory area.
Upon evaluating current problems and desired information (input and output), the analyst begins to synthesize one or more solutions. To begin, the data objects, processing functions, and behavior of the system are defined in detail. Once this information has been established, basic architectures for implementation are considered.
A client/server approach would seem to be appropriate, but does the software to support this architecture fall within the scope outlined in the Software Plan? A database management system would seem to be required, but is the user/customer's need for
docsity.com
The next set of questions enables the analyst to gain a better understanding of the problem and the customer to voice his or her perceptions about a solution:
- How would you characterize "good" output that would be generated by a successful solution?
- What problem(s) will this solution address?
- Can you show me (or describe) the environment in which the solution will be used?
- Will special performance issues or constraints affect the way the solution is approached?
The final set of questions focuses on the effectiveness of the meeting. Gause and Weinberg call these meta-questions and propose the following (abbreviated) list:
- Are you the right person to answer these questions? Are your answers "official"?
- Are my questions relevant to the problem that you have?
- Am I asking too many questions?
- Can anyone else provide additional information?
- Should I be asking you anything else?
These questions (and others) will help to "break the ice" and initiate the communication that is essential to successful analysis. But a question and answer meeting format is not an approach that has been overwhelmingly successful. In fact, the Q&A session should be used for the first encounter only and then replaced by a meeting format that combines elements of problem solving, negotiation, and specification.
2. Facilitated Application Specification Techniques
Too often, customers and software engineers have an unconscious "us and them" mind-set. Rather than working as a team to identify and refine requirements, each constituency defines its own "territory" and communicates through a series of memos, formal position papers, documents, and question and answer sessions. History has shown that this approach doesn't work very well. Misunderstandings abound, important information is omitted, and a successful working relationship is never established.
It is with these problems in mind that a number of independent investigators have developed a team-oriented approach to requirements gathering that is applied during early stages of
docsity.com
analysis and specification. Called facilitated application specification techniques "(FAST).
This approach encourages the creation of a joint team of customers and developers who work together to: Identify the problem Propose elements of the solution Negotiate different approaches and specify a preliminary set of solution requirements.
FAST has been used predominantly by the information systems community, but the technique offers potential for improved communication in applications of all kinds.
Many different approaches to FAST have been proposed. Each makes use of a slightly different scenario, but all apply some variation on the following basic guidelines:
- A meeting is conducted at a neutral site and attended by both software engineers and customers.
- Rules for preparation and participation are established.
- An agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of ideas.
- A ‘facilitator’ (can be a; customer, a developer, or an outsider) controls the meeting.
- A "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used.
The goal is to identify the problem, propose elements of the solution, negotiate different approaches, and specify a preliminary set of solution requirements in an atmosphere that is conducive to the accomplishment of the goal.
To better understand the flow of events as they occur in a typical FAST meeting, we present a brief scenario that outlines the sequence of events that lead up to the meeting, occur during the meeting, and follow the meeting.
Initial meetings between the developer and customer occur and basic questions and answers help to establish the scope of the problem and the overall perception of a solution. Out of these initial meetings, the developer and customer write a one- or two- page "product request." A meeting place, time, and date for FAST are selected and a facilitator is chosen. Attendees from both the
docsity.com
- The analysis process should move from essential information toward implementation detail. 6. Software Prototyping
Analysis should be conducted regardless of the SW engineering paradigm. (Various approaches apply)
In some cases it is possible to apply operational analysis principles and derive a model of SW from which a design can be developed.
In other situation Requirement Elicitation (FAST, QFD etc) is conducted and a model is built, called Prototype.
docsity.com
