1 / 16

Maximizing Software Efficiency: The Role and Process of Requirements Analysis

Discover the purpose and tasks of requirements analysis, bridging the gap between system level allocation and design. Explore the importance of refining software allocation, modeling process, data, and behavioral domains, and specifying design constraints. Gain insights into the essential and implementation views, essential principles, and the role of an analyst. Dive into problem areas, communication skills, and facilitated application specification techniques. Uncover essential information about software applications, domains, principles, and the modeling and specification process.

lizina
Download Presentation

Maximizing Software Efficiency: The Role and Process of Requirements Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

  11. 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)

  12. 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)

  13. 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

  14. 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)

More Related