Purpose of Requirements Analysis Process of discover, refinement, modeling, and specification o Bridge gap between system level SW allocation and design.
Published byModified over 4 years ago
Presentation on theme: "Purpose of Requirements Analysis Process of discover, refinement, modeling, and specification o Bridge gap between system level SW allocation and design."— Presentation transcript:
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
Analysis Tasks o Problem Recognition o Evaluation and synthesis o Modeling o Specification, o Review
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?
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)
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
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)
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.
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)
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
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
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)
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)
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
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)