Requirement Analysis

The systematic use of proven principles, techniques ,languages and tools for the cost-effective analysis ,documentation and on-going evolution of user needs and the external behavior of a system to satisfy those user needs.
Requirement Elicitation
Facilitated Application Specification Technique(FAST)
Quality Function Deployment
USE-CASES

1. Requirement Analysis

2. Analysis Concepts and Principles Requirements Engineering The systematic use of proven principles, techniques ,languages and tools for the cost-effective analysis ,documentation and on-going evolution of user needs and the external behavior of a system to satisfy those user needs.

3. Analysis Concepts and Principles Requirement Analysis This task is done to understand the specific requirements that must be achieved to build high quality software. One who perform this task is called System Analyst .   If analysis is not done properly, then it may result in a software which is a solution of a wrong problem.   It will lead to waste of money and time, personal frustration and unhappy customers. Requirement analysis is a software engineering task that bridges the gap between system level requirements engineering and software design.

4. Analysis Concepts and Principles

5. Analysis Concepts and Principles Requirements engineering activities results in: the specification of software’s operational characteristics (function, data and behavioral). Indicate software’s interface with other system elements and establish constraints that the software must meet.

6. Analysis Concepts and Principles Requirement analysis : allows the software engineer(system analyst) to refine software allocation and build models of the data ,functional and behavioral domains that will be treated by software.   Provides the software designer with a representation of information ,function and behavior that can be translated to data ,architectural, interface and component level designs.   The requirement specification provides the developer and the customer with the means to assess quality once software is built.

7. Software Requirement Analysis Software requirement analysis may be divided into five areas of effort: Problem recognition Evaluation and Synthesis Modeling Specification Review

8. Software Requirement Analysis Problem recognition: Initially ,the system analyst studies the system specification and the software project plan. Next, communication must be established for analysis so that problem recognition is ensured. The goal is recognition of the basic problem elements as perceived by the customers/users. Problem Evaluation and Solution synthesis: a)Problem Evaluation The analyst must define all externally observable data objects . Evaluate the flow and content of information . Define and elaborate all software functions . understand software behavior in the context of events that affect the system Establish system, interface characteristics Uncover additional design constraints.

9. Software Requirement Analysis b) Solution synthesis: Upon evaluating current problems and desired information (input and output),the analyst begins to synthesize one or more solutions. First, data objects ,processing functions and behavior of the system are defined in detail. Second, the basic architecture for implementation are considered. 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 synthesis ,the analyst‘s primary focus is on “what” and not “how”.   i.e. what does the system produce and consume, what functions must the system perform, what behaviors does the system exhibit, what interfaces are defined and what constraints apply.

10. Software Requirement Analysis Modeling the analyst creates models of the system in an effort to better understand data and control flow ,functional processing ,operational behavior and information content.   Specification Modeling serves as the foundation of specification.   Review Specification is reviewed by both analyst and customers  

11. Requirement Elicitation for Software Before the requirements can be analyzed, modeled or specified ,they must be gathered through an elicitation process. A customer will have a problem that is amenable to a computer-based solution. The developer will respond to the customer’s request for help. Thus communication between customer and developer begins.

12. Requirement Elicitation for Software Initiating the process Most commonly used requirement elicitation technique is to conduct a meeting or interview. First meeting may not lead to get a clear idea, so they should continue the communication. Analyst should ask some context-free questions. i.e. a set of questions that lead to a basic understanding of the problem, the people who want a solution, the nature of the solution that is desired and the effectiveness of the first encounter itself. The first set of questions focuses on the customer, the overall goals and the benefits. Who is behind the request for this work? Who will use the solution? What will be the economic benefit of a successful solution? Is there another source for the solution that you need?

13. Requirement Elicitation for Software The next set of questions enables the analyst to gain better understanding of the problem and the customer to voice his or her perceptions about a solution: How could you characterize “good” output that would be generated by a successful solution? What problem(s) will this solution address? Can you show me the environment in which the solution will be used? Will special performance issues or constraints affect the way the solution is approached?

14. Requirement Elicitation for Software The final set of questions focuses on the effectiveness of the meeting: Are you the right person to answer these questions? Are your answers official? Are my questions relevant to the problems that you may have? Am I asking too many questions? Can anyone else provide additional information. Should I be asking you anything else?

15. Requirement Elicitation for Software These questions will help to initiate the communication that is essential to successful analysis. The question and answer meeting is not always successful . It is useful for first encounter only. Then it is replaced by a meeting format that combines elements of problem solving, negotiation and specification.

16. Facilitated Application Specification Technique(FAST ) Using question and answer meeting to identify and refine requirements ,there may be misunderstandings, omissions of information and a successful working relationship is never established. Therefore a team-oriented approach is used to requirements gatherings that is applied during early stages of analysis and specification. FAST is a technique used for that accomplish a team-oriented approach.

17. Facilitated Application Specification Technique(FAST) FAST is an approach that encourages : the creation of a joint team of customers and developers, who works together to identify the problem, propose elements to the solution negotiate different approaches and specify a preliminary set of solution requirements.

18. Facilitated Application Specification Technique(FAST ) Many different approaches to FAST have been proposed, each using a different scenario. Basic guidelines followed by FAST: 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) is chosen.   A “definition mechanism”(can be a worksheets ,flip charts or wall stickers or an election bulletin board, chat room or virtual forum) is used.

19. Facilitated Application Specification Technique(FAST ) 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 conductive to accomplishment of the goal

20. Facilitated Application Specification Technique(FAST ) Sequence of events in FAST include: Initial meetings between the developer and customer occur and basic questions and answer 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 facilitator is chosen. Attendees from both the development and customer/user organizations are invited to attend. The product request is distributed to all attendees before the meeting date.

21. Facilitated Application Specification Technique(FAST ) While reviewing the request in the days before the meeting ,each FAST attendee is asked to make a list of : objects that are part of environment that surrounds the system, other objects that are produced by the system and objects that are used by the system to perform its functions .

22. Facilitated Application Specification Technique(FAST ) In addition, each attendee is asked to make another list of services (processes or functions) that manipulate or interact with the objects. Finally ,list of constraints (e.g. cost, size ,business rules ) and performance criteria (e.g. speed , accuracy) are also developed.

23. Facilitated Application Specification Technique(FAST ) E.g. Product: "Safe Home ” ( to avoid and protect undesirable situations such as illegal entry, fire ,flooding etc.) Here FAST team may contain representation from marketing, software and hardware engineering and manufacturing. An outside facilitator is to be used. Objects may include: smoke detectors window and door sensors motion detectors, an alarm an event, a control panel a display, telephone numbers telephone call etc.

24. Facilitated Application Specification Technique(FAST ) List of services include: setting the alarm monitoring the sensors dialing the phone programming the control panel reading the display etc. List of constraints include: Cost of manufacture should be less than $80. Must be user-friendly. Must interface directly to a standard phone line. Performance criteria include: Sensor event should be recognized within one second. An event priority scheme should be implemented.

25. Facilitated Application Specification Technique(FAST ) As the FAST meeting begins ,the first topic of discussion is the need and justification for the new product-everyone should agree that the product is justified. Once the agreement has been established each participant presents his/her list for discussion. It is pinned on the walls of the room using large sheets of paper, or written on a wall board or posted on a electronic bulletin board for review prior to the meeting. Each list should be capable of being manipulated separately so that lists can be combined, entries can be deleted and additions can be made. At this stage critique and debate are strictly prohibited.

26. Facilitated Application Specification Technique(FAST ) After individual lists are presented in one topic area, a combined list is created by the group. The combined group eliminates redundant entries, adds any new ideas that come up during discussion ,but does not delete anything. After combined lists for all topic areas have been created ,discussion coordinated by the facilitator ensues.

27. Facilitated Application Specification Technique(FAST ) The combined list is shortened ,lengthened or reworded to properly reflect the product/system to be developed. The objective is to develop a consensus list in each topic area. (objectives , services , constraints and performance)   The lists are then set aside for later action. Once the consensus list have been completed ,the team is divided into smaller sub-teams ; each work to develop mini-specifications for one or more entries on each of the lists.

28. Facilitated Application Specification Technique(FAST ) E.g. For Safe Home Project ,mini-specification for control panel Mounted on the wall Size approximately 9×5 inches Contain standard 12-key pad and special keys Contain LCD display Customer interaction through keys Connected to all sensors. Each sub team then presents each of its mini-specs to all FAST attendees for discussion. Additions ,deletions and further elaboration are made. After the mini-specs are completed ,each FAST attendee make a list of validation criteria for the product/system and present his/her list to the team. A consensus list of validation criteria is then created. Finally one or more participants is assigned to task of writing the complete draft specification using all inputs from the FAST meeting.

29. Quality Function Deployment(QFD) QFD is a quality management technique that translates the needs of the customer into technical requirements for software. QFD concentrates on maximizing customer satisfaction from the software engineering process. QFD emphasizes an understanding of what is valuable to the customer and then displays these values throughout the engineering process.

30. Quality Function Deployment(QFD) QFD identifies three types of requirements: Normal Requirements The objectives and goals that are stated for a product or system during meetings with the customer. If these requirements are present ,customer is satisfied. examples of normal requirements might be requested type of graphical displays ,specific system functions and defined level of performance. Expected Requirements These requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them. Their absence will be a cause of significant dissatisfaction. Examples of expected requirements are: Human/machine interaction Overall operational correctness Reliability and ease of software installation.

31. Quality Function Deployment(QFD) Exciting Requirements These features go beyond the customer’s expectations and prove to be very satisfying when present. For e.g. word processing software is requested with standard features. The delivered product contains a no. of page layout capabilities that are quite pleasing and unexpected.

32. Quality Function Deployment(QFD) QFD spans the entire engineering process. Concepts adapted for a computer software during the meeting with the customer are: Function deployment : Used to determine the value of each function that is required for the system Information deployment Identifies both the data objects and events that the system must consume and produce. These are tied to functions. Task deployment Examines the behavior of the system or product within the context of its environment. Value Analysis Is conducted to determine the relative priority of requirements determined during each of the three deployments

33. Quality Function Deployment(QFD) QFD uses customer interviews and observations ,surveys and examination of historical data(e.g. Problem report) as raw data for requirements gathering activity. These data are the translated into a table of requirements –called customer voice table – that is reviewed by the customer . A variety of diagrams ,matrices and evaluation methods are the used to extract expected requirements and to attempt to derive exciting requirements.

34. USE-CASES USE-CASES As the requirements are gathered as a part of informal meeting ,FAST or QFD ,the software engineer (analyst) can create a set scenarios that identify a thread of usage for the system to be constructed . The scenarios ,called as use-cases provide a description of how the system will be used. To create a use-case ,the system analyst must first identify the different types of people or device that use the system or product and are called actors . These actors usually represent roles that people play as the system operates. Actor : is anything that communicates with the system or product and that is external to the system itself. Actor and user are not the same thing. A user may play a no. of different roles when using a system, while an actor plays only one role.  

35. USE-CASES E.g. Consider a machine operator (a user) who interacts with a control computer for a manufacturing cell, that contain no. of robots and numerically controlled panels. Software for the control computer has four different modes (roles) of interaction: programming mode, testing mode, monitoring mode and troubleshooting mode.. Therefore four actors can be defined: programmer, tester, monitor and troubleshooter In some cases ,the machine operator may play all these roles or in other different people may play the role of each actor.

36. USE-CASES Requirements elicitation can be evolutionary . So all actors are not identified during the first iteration i.e. primary actors in the first iteration, secondary in the next and so on Once the actors have been identified , use-cases can be developed. The use-cases describes the manner in which an actor interacts with the system.

37. USE-CASES Some questions that are to be answered by the use-cases: What main tasks or functions are performed by the actor? What system information will the actor acquire, produce or change? Will the actor have to inform the system about changes in the external environment? What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes?

38. USE-CASES Use-case Is a written narrative that describes ,the role of an actor as interaction with the system occurs. Each use-case provides an unambiguous scenario of interaction between the actor and the software. It can also be used to specify timing requirements or other constraints for the scenario.

39. Analysis Principles Large no. of analysis modeling methods have been developed. All methods are related by a set of operational principles: The information domain of a problem must be represented and understood.   The functions that the software is to perform must be defined.   The behavior of the software (as a consequence of external events) must be represented.   The models that depict information ,function and behavior must be partitioned in a manner that uncovers detail in a layered or hierarchical fashion.   The analysis process should move from essential information toward implementation detail.

40. Analysis Principles Some guiding principles for requirements engineering are: Understand the problem before you begin the analysis model. Rushing to a solution before understanding the problem leads to an elegant software that solves a wrong problem. Develop prototypes that enable a user to understand how human/machine interaction will occur. Record the origin and the reason for every requirements. Use multiple views of requirements Building data, functional and behavioral model provide three different views Rank requirements Work to eliminate ambiguity

41. The Information Domain Software applications are called data processing. It accept input, manipulate it in some way and produce output. Software also processes events . An event represents some aspect of system control and is a Boolean data. For e.g. ,a pressure sensor detects that the pressure exceeds a safe value and sends an alarm signal to monitoring software. The alarm signal is an event that controls the behavior of the system. The data (text, number, image etc. )and control (events) both reside within the information domain of a problem.

42. The Information Domain The information domain contain three different views of data and control as each is processed by a computer program: Information content and relationships(data model) Information flow Information structure

43. The Information Domain Information content and relationship: information content --> represent the individual data and control objects there are different relationships between data and objects Information flow: represents the manner in which data and control change as each moves through a system. Input objects are transformed to intermediate information (data and /or control),which is further transformed to output. Along this transformation path ,additional information can be introduced from an existing data store(e.g. a disk file or memory buffer) Data and control that moves between two transformations (functions) define the interface for each function.

44. The Information Domain Information structure: represent the internal organization of various data and control items and tell whether it is organized as - data tree structure - data table (n-dimension)

45. Modeling Models are created to gain a better understanding of the actual entity to be built. For a physical thing ,we can build model with identical form and shape but smaller scale. But for software it takes a different form. It must be capable of representing: the information that software transforms, the functions(and sub functions) Events that enable the transformation to occur and the behavior of the system as the transformation is taking place. Types of models include: Functional Models Behavioral Models

46. Modeling Functional models Software transforms information , and for that it has to perform at least three functions: input ,processing and output. While creating functional models, software engineer focuses on problem specific functions. The functional model begins with a single context level model(name of the software) Over a series of iterations ,more and more functional detail is provided until complete functionality is presented.

47. Modeling Behavioral model Most software responds to events from the outside world. This stimulus/response characteristic forms the basis of behavioral model. Software states(waiting , computing , printing)is changed when some event occurs.  

48. Important roles of models : The model aids the analyst in understanding the information, function, and behavior of a system. The model becomes the focal point for review in the aspects of completeness, consistency, and accuracy of the specification. The model becomes the foundation for design, providing the designer with an essential representation of software that can be mapped into an implementation context.

49. Partitioning Partitioning decomposes a problem into its constituent parts. Establish a hierarchical representation of information (or function) and then partition the uppermost element by: - exposing increasing detail by moving vertically in the hierarchy - functionally decomposing the problem by moving horizontally in the hierarchy.

50. Partitioning

51. Software Prototyping After requirement elicitation and applying analysis principles, a model of the software to be built ,called a prototype is constructed for customer and developer assessment. This model then evolves into production software. The prototyping approach can be either close-ended or open-ended. The closed-ended approach is called throwaway prototyping . a prototype serves only as a rough demonstration of requirements. it is then discarded and the software is engineered using a different paradigm. The open-ended approach is called evolutionary prototyping . - a prototype serves as the first evolution of the finished system.  

52. Software Prototyping Before choosing the approach it is necessary to determine whether the system to be built is amenable to prototyping . This is done based on the factors like application area ,application complexity, customer characteristics and project characteristics. If the software application demands dynamic visual displays or if it interacts heavily with the user ,then the evolutionary fashion is used. If the software has tens of thousands of lines of code, then prototyping the software becomes complex. It can be done in parts by partitioning the complexity.

53. Prototyping Methods and Tools Software prototyping to be effective ,a prototype must be developed rapidly so that the customer may assess results and recommend changes. Prototyping Methods and Tools: - Fourth Generation Techniques Encompass a broad array of database query and reporting languages, program and application generators and other very high level non procedural languages. - Reusable Software Components Prototyping can be done by a assembling rather than building by using a set of existing software components. Formal specification languages and tools have been developed . It provides interactive environments that Enable an analyst to interactively create language-based specifications of a system or a software. Invoke automated tools that translate the language-based specifications into executable code. Enable the customer to use prototype executable code to refine formal requirements.

54. Specification Requirements are represented in a manner that ultimately leads to successful software implementation Specification principles include: Separate functionality from implementation Develop a model of the desired behavior of a system Establish the context in which software operates Define the environment in which the system operates Create a cognitive model rather than a design or implementation model Specification is an abstract model of a real system Establish the content and structure of a specification (easy to be changed)

55. Representation Guidelines for representation: Representation format and content should be relevant to the problem A general format for SRS can be developed Vary with application area. i.e. symbology , diagrams and language used for specification may differ. Information contained within the specification should be nested Representations should reveal layers of information so that a reader can move to the level of detail required. Paragraph and diagram numbering should indicate the level of detail required. Diagrams and other notational forms should be restricted in number and consistent in use Confusing or inconsistent Notation ,whether graphical or symbolic ,degrades understanding and fosters errors Representations should be revisable The content of specification will change . Ideally CASE tools should be available to update all representations that are affected by each change.

56. Software Requirement Specification A Software Requirement Specification is produced at the culmination of the analysis task. Organization of Software Requirement Specification : Introduction Information description Functional description Behavioral description Validation criteria Bibliography and Appendix

57. Software Requirement Specification Introduction States the goals and objectives of the software. It is the software scope of the planning document. Information description Provides the detailed description about the problem that the software must solve. Information content, flow and structure are documented . Hardware ,software and human interfaces are described for external system elements and internal software functions

58. Software Requirement Specification Functional description Description of each function required to solve the problem A processing narrative is provided for each function Design constraints are stated and justified. Performance characteristics are stated Graphically represent the overall structure of the software and interplay among software functions and other system elements. Behavioral description Examines the operations of the software as a consequence of external events and internally generated control characteristics.

59. Software Requirement Specification Validation criteria How do we recognize a successful implementation? What classes of tests must be conducted to validate function, performance and constraints? Bibliography and Appendix Bibliography contains references to all documents that relate to the software. Include other software engineering documentation, technical references, vendor literature and standards. Appendix contains information that supplements the specifications. Tabular data ,detailed description of algorithms, charts, graphs and other materials.

60. Software Requirement Specification In many cases ,the Software Requirement Specification may be accompanied by an executable prototype or a paper prototype or a Preliminary User’s Manual . The manual is a valuable tool for uncovering problems at the human/machine interface.

61. Specification review A review of Software Requirement Specification is conducted by both software developer and the customer.   Review is first conducted at the macroscopic level.   Reviewers must first ensure that specification is complete, consistent and accurate.   In detailed review ,vague terms are specified for further clarification.   Once the review is complete , “Software Requirement Specification “ is signed off by both customer and developer.   The specification becomes a “ contract ” for software development.