Purpose of Requirements Analysis

1. Purpose of Requirements Analysis Process of discover, refinement, modeling, and specification • o Bridge gap between system level SW allocation and • design • o Enable system engineer to specify software function • and performance • o Indicate SW interface with other system elements • o Establish design constraints • o Analyst must : • - Refine SW allocation and • - build models of the process, data, and behavioral • domains • o RA provides SW designer with representation of info • and function • can be translated into data, architectural, and proce- • dural design. • o Allow developer and customer to assess quality

2. Analysis Tasks • o Problem Recognition • o Evaluation and synthesis • o Modeling • o Specification, • o Review

3. Role of Analyst • o Evaluate flow and content of information • o Define and elaborate all SW functions • o Understand SW behavior in context of events affecting • system • o Establish system interface characteristics • o Uncover design constraints • o Remember, assessing the WHAT! • - What data? • - What functions must system perform? • - What interfaces? • - What constraints apply?

4. Problem Areas • o Communication Skills (different levels) • - High-level interaction • - More detail extraction from customer • - Tailor communication approach towards customer • o Facilitated Application Specification Techniques (FAST) • Joint team of customer with developers (marketing, an- • alysts, programmers, HW engrs)

5. Analysis Principles • o Information domain of problem must be represented • and understood. • o Develop models that illustrate system info, function, • and behavior • o Models and problem should be decomposed into hier- • archical organization • o Process progress from essential (high-level requirements) • to implementation details

6. Information Domain • o All SW applications can be called data processing. • Software is built to process data • o SW also processes events • o data and control (events) both reside within the Info • Domain • o 3 views of data and control as processed by computer • programs • 1. Information_Flow:______how data and control change as • they move through system • 2. Information_content:______represents individual data and • control items making larger items of information • (components wrt to data and events) 3. Information_structure:______Internal organization of data • control items (e.g. table, tree)

7. Modeling and Specification • o Modeling____ • - Aid in understanding information, function, and be- • havior of system. • - Focal point for review (determine completeness, con- • sistency, and accuracy of specification) • - Foundation for design: ("mapping" from presenta- • tion to implementation context. • o Partitioning/Decomposition_________ • - Decompose large/complex problem into easily un- • derstandable parts • - Establish interfaces between parts to achieve overall • functionality. • - Strive for hierarchical representation: • (partition uppermost element according to the fol- • lowing) • O Increase detail by moving vertically • O Increase breadth or functionality by moving hor- • izontally.

8. Essential and Implementation Views • o Essential_View____ • of SW requirements: • - Presents functions to be accomplished • - Information to be processed • - Without regard to implementation details • o Implementation_View________ • of SW requirements: • - Presents "real-world" implementation perspective • of processing functions and information data struc- • tures • - May be physical representation (depending on the • objective)

9. Prototyping • o Prototype is mostly for customer assessment • o Several_steps_of_prototyping:_______ • 1. Evaluate SW request and determine if feasible. • 2. Develop abbreviated representation of requirements • 3. Develop abbreviated design specification from re- • quirements • 4. Prototype SW is created, tested, and refined • paper prototype through pictorial representations • 5. Present prototype to customer: obtain feedback, • then refine • o Prototyping_Methods_and_Tools___________ • - Fourth-generation techniques (database and report • languages) • - Reusable SW components • - Formal Specification and Prototyping environments • O Executable spec languages • O Translate specs into exec. code

10. Specification • Formal spec languages lead to formal representation of • requirements that may be verified or further analyzed • Specification_Principles:_____ • o Cognitive model (take user's perspective) • o Operational (be able to verify) • o Tolerant of incompleteness and modifiable (abstract, • may need refinement) • o Localized and loosely coupled

12. Representation Guidelines • o Representation format and content should be relevant • to problem • o Information contained within specification should be • nested • o Limited number of and consistent use of diagrams and • other notational forms • o Revisable representation (CASE tools)

14. Software Requirements Specification • o Function and performance allocated to SW from sys- • tem engineering should be refined by: • - establishing complete information description • - detailed functional description • - performance requirements and design constraints • - validation criteria • o Standard formats (example: IEEE no. 830-1984)

15. Specification Contents • - Introduction states goals and objectives of SW • describe context of computer-based system • - Information Description gives detailed descrip- • tion of problem • O Information flow and structure documented • O HW, SW, and human interfaces described for ex- • ternal system elements and internal SW functions • - Functional Description description of each func- • tion needed to solve the problem • O Processing narrative for each function • O Design constraints: state and justify • O Give performance characteristics • O One or more graphical diagrams represent overall • structure and interaction between SW functions • and other system elements

16. Specification Contents • - Behavioral Description examines operation of SW • as consequence of • O external events and • O internally generated control characteristics • - Validation Criteria: (very important) • O "How do we know if SW is successful implemen- • tation?" • O "What classes of tests are necessary to validate • function, performance, and constraints?" • - Bibliography contains references to all documents • that relate to software • O SE documentation (e.g., Handbook) • O Technical references (e.g., Algorithm texts, Pro- • gramming Language texts, Manuals) • O Vendor Literature (e.g., Sun OpenWindows) • O Standards (IEEE requirements standards)