Requirements Analysis The process of Discovering, Refinement, Modeling and Requirement Analysis Specification in a software project. Involve both the Customer and System Engineer Fundamentals Allowing system engineer to achieve a set of objectives: Specify software function and performance Peter Lo Indicate software interface with other system elements Establish design constraints that the software must meet Provides the software designer with a representation of Information and Function that can be translated to Data, Architectural and Procedural Design. CS213 © Peter Lo 2005 1 CS213 © Peter Lo 2005 2 Requirements Analysis Software Requirement Analysis Preparation of the Software Specification: Divided into 5 main areas: It is a formal document that specifies in precise Problem Recognition terms the functional and performance requirements of the software. Evaluation and Synthesis Modeling Specification document in turn will allow the developer and customer to assess quality once Specification the software itself has been built. Review The software developer performing Requirement analysis would often be known as the Analyst CS213 © Peter Lo 2005 3 CS213 © Peter Lo 2005 4 Problem Recognition Evaluation and Synthesis Recognize the basic problem elements perceived Evaluate the flow and content of information by user and customer Define and elaborate all software functions Understand software behavior in the context of events that Understand software in the system context affect the system Define software scope Establish system interface characteristics and uncover design constraints Establish contact with management and technical Emphasis on what must be done, not how it will be staff of the customer and software development done organization This step will continue until both the analyst and customer feels confident that software can be adequately specified for subsequent development steps CS213 © Peter Lo 2005 5 CS213 © Peter Lo 2005 6 Modeling Specification Create models of the system that will enable better understanding of A representation of software that can be reviewed data and control flow Describe the data and control flow, functional processing, behavioral and approved by the customer. operation, and information content Developed as a joint effort between the developer Models serve a number of important roles: Aids in understanding the information, function and behavior of a and the customer. system Makes requirement analysis task easier and more systematic Serves as a basis for creating specification for the software Becomes the focal point for review Becomes the foundation for design CS213 © Peter Lo 2005 7 CS213 © Peter Lo 2005 8 Separate Functionality from Specification Principles Implementation 1. Separate Functionality from Implementation A specification is a description of what you want 2. A Process-oriented Systems Specification Language is Required (i.e. you specify), as opposed to how it is realized 3. Encompass the System of which the Software is (i.e. implementation). Component 4. Encompass the Environment in which the System Operates 5. Cognitive Model 6. Operational 7. Tolerant of Incompleteness and Augmentable 8. Localized and Loosely Coupled CS213 © Peter Lo 2005 9 CS213 © Peter Lo 2005 10 A Process-oriented Systems Encompass the System of Software is Specification Language is Required Component In a dynamic environment, the behavior of the System is made up of interacting components entity cannot be expressed as a mathematical Specifications must be made in context of entire function of its input system and interaction between its parts A process-oriented description must be employed, in which the "what" specification is achieved by specifying a model of the desired behavior in terms of functional responses to various stimuli from the environment CS213 © Peter Lo 2005 11 CS213 © Peter Lo 2005 12 Encompass the Environment the A Cognitive Model System Operates The environment in which the system operates and It means that the specification must describe a how it interacts with must be specified system as perceived by its user community, and should not be too abstract. CS213 © Peter Lo 2005 13 CS213 © Peter Lo 2005 14 Tolerant of Incompleteness and Operational Augmentable The specification must be complete and formal The specification must be robust enough to enough such that it can be satisfy an undergo changes, expansion. implementation of some arbitrary test cases. CS213 © Peter Lo 2005 15 CS213 © Peter Lo 2005 16 Localized and Loosely Coupled Review Localized means to affect one piece only Review of analysis documents like specification Loosely coupled means that parts can be removed Conducted at a macroscopic level. or added easily Conducted by customer and developer. Results in modifications: The specification must be such that its content and structure should be able to accommodate dynamic Functions changes, and that whatever information changes Performance there are, it should affect one component only. Information representation Constraints Validation criteria CS213 © Peter Lo 2005 17 CS213 © Peter Lo 2005 18 Responsibility of Analyst Ability that Analyst should have To analyze and define systems of optimum Grasp abstract concept, partition them and performance generate solutions based on each division i.e. an output that fully meets management Understand implicit information, separate them objectives and treat them individually Absorb pertinent facts from conflicting sources Understand the customer environment Apply hardware and/or software system elements to the customer environment Communicate well in written and verbal form CS213 © Peter Lo 2005 19 CS213 © Peter Lo 2005 20 Problems in Requirement Analysis Causes for the Problems Requirement analysis is a communication-intensive Poor communication that makes information activity. acquisition difficult Problems like miscommunication and omission often Inadequate techniques and tools for developing occur between analyst and customer. specification Successful acquisition of information cannot be Tendency to take short-cuts during requirements guaranteed because analyst have difficulties: analysis tasks, leading to unstable design 1. In getting pertinent (appropriate) information Failure to consider alternative solutions before 2. Handling large and complex problems software is specified on both parts of analyst and 3. Accommodating changes that occur during and after customer. analysis CS213 © Peter Lo 2005 21 CS213 © Peter Lo 2005 22 Communication Techniques Preliminary Meeting or Interview Communication techniques are not fact-finding Proposed by Gause and Weinberg. (information gathering) techniques, The commonly used analysis technique to bridge Two techniques are available to tackle these the communication gap between the customer and communication problems developer. Preliminary Meeting or Interview Though effective for a first meeting, it should Facilitated Application Specification Technique not be used for subsequent meetings between (FAST) the customer and software developer. CS213 © Peter Lo 2005 23 CS213 © Peter Lo 2005 24 Preliminary Meeting or Interview First Set of Questions The technique comprises of 3 different sets of These questions lead to a basic understanding of questions the problem These questions help to initiate the communication Focuses on the customer and overall goals and that is essential to successful analysis. benefits This approach should be used as a first encounter Example: only, and then replaced by a meeting format that Who is behind the request for this work? combines elements of problem solving, negotiation and specification. CS213 © Peter Lo 2005 25 CS213 © Peter Lo 2005 26 Second Set of Questions Third Set of Questions These questions enable the analyst to gain a better Focuses on the effectiveness of the meeting itself. picture of the problem. These questions are often called “meta-questions”. Allow the customer to voice his perceptions about Example: a solution. Are you the right person to answer these Example: questions? What problems will this solution address? CS213 © Peter Lo 2005 27 CS213 © Peter Lo 2005 28 Facilitated Application Goal of FAST Specification Technique (FAST) A technique that is used after the first meeting is The basic Goals of the FAST meeting are completed and basic understanding has been achieved. Identify the problem It proposes a meeting format that combines elements of Problem Solving, Negotiation, and Specification. Propose elements of the solution The FAST mentality encourages the working together Negotiate different approaches mentality rather than working individually. Specify a preliminary set of solution The technique is a team-oriented approach, the team jointly requirements. made up of customers and developers. CS213 © Peter Lo 2005 29 CS213 © Peter Lo 2005 30 Fundamental Principles of Analysis Basic Guidelines of FAST Methods There are different approaches to FAST, but all of The information domain of a problem must be represented them have the following basic guidelines: and understood Meeting is conducted at a neutral site The functions that the software is to perform must be defined Rules for preparation and participation are established The behavior of the software must be represented The models that depict information, function, and behavior An agenda is suggested to cover all the important points. must be partitioned in a manner that uncovers