1 / 14

Software Requirements Management

Colorado Technical University CS455 Jack Simmonds Instructor: Crispin Jose 5/4/2014. Software Requirements Management. Summary of IEEE Standards 830 & 1233a CMMI – System and Project metrics & management Goals & Practices for Requirements Management

donnel
Download Presentation

Software Requirements Management

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. Colorado Technical University CS455 • Jack Simmonds • Instructor: Crispin Jose • 5/4/2014 Software Requirements Management

  2. Summary of IEEE Standards 830 & 1233a • CMMI – System and Project metrics & management • Goals & Practices for Requirements Management • Available Tools for Requirements Management • Producing Metrics Through Requirements Management • Summary Topics of Discussion

  3. IEEE 830-1998 aims at specifying best practices for creating SRS documents and the requirements they contain. One of the main goals is to provide a methodology and framework for developing software through the organized conversion of client needs and objectives into functional requirements (Software Engineering Standards Committee). This approach ensures that future developers, tasked with working on an existing project, save time and effort when modifying or enhancing previously completed software. It further provides a documented basis for common understanding between software suppliers and customers & promotes the development of reusable software modules. Summary of IEEE 830 & 1233 Standards

  4. IEEE 1233a–1998 provides a guide for the development of System Requirements Specification (SyRS). SyRS includes not just the SRS but all elements involved with any input, output, interaction, or interface with software defined by that SRS, the actors involved and the environment in which it operates (Software Engineering Standards Committee). • Both standards include templates designed to assist in creating SRS and other project related documents. IEEE Summary Continued

  5. CMM measures the maturity of the software development process on a scale of 1 to 5. CMMI integrates CMM across software development, systems engineering, product or process development and supplier sourcing. Each or all of those disciplines may be selected from the CMMI at the time of implementation by a business or other organization(Carnegie Mellon, 2014). The idea is to establish a standard framework for process improvement Carnegie Mellon(2014). • It is hoped that application of CMMI will increase customer satisfaction and system development efficiency by applying an emphasis on planning, monitoring, measuring, and improving predictability for all stakeholders involved in a system. Processes are rated for maturity level according to five stages of refinement: initial, repeatable (managed), defined, managed (quantitatively), optimized (Hartman). CMMI

  6. Requirements management is part of a group of quality directed process control behaviors that also includes a focus on verification, validation and quality assurance (Carnegie Mellon, CMMI & Business Objectives). The purpose of REQM is to reveal inconsistencies between developed requirements and the project stakeholders' goals and needs. REQM is considered a maturity level 2 process within the CMMI and is also used to define and implement the requirements change control process (Carnegie Mellon, Process Area 17). • CMM provides a framework for measuring the levels of maturity of the processes involved within a software development process. These maturity levels provide an industry standard for reducing risk whether a software project is ready for customer deployment or requires more development to meet customer requirements, and is being developed in a manner that allows for continued improvement, through change or enhancement, once deployed. purpose of REQM within CMMI

  7. Requirements management is an indication that maturity level 2 has been achieved within a staged representation of organizational process improvement. This is especially true when the software development process also includes project planning, monitoring and control, measurement and analysis (not yet at the level of complete verification and validation which is an indicator of level 3). (Carnegie Mellon, Maturity levels and Process areas) REQM within CMMI (continued)

  8. Traceability • Usability • Maintainability • Version control • Security constraints • Performance • Reusability • Verification & Validation REQM Goals & Practices USED for CS455

  9. aNimble Platform: available from sourceforge (ideastub, 2014) • Provides a requirements management tool that includes traceability, version control, change control, searchable requirements, and a GUI for rapid training and increased usibility. • aNimble is available free as a downloadable software package (including its own local server/database) or as a cloud based service. • aNimble is open source software. Any updates are automatically applied to the cloud based version. Identification of a Requirements management tool

  10. REQM involves both change control and traceability. These attributes are both naturally comprised of elements that provide measurable metrics. For traceability every requirement is given an identifying label which can be used to trace the original source of the requirement, its dependencies and any sibling or child relationships. The primary evaluating metric for traceability is a traceability matrix (Jose, C., 2014). The matrix displays a table showing each requirement, a brief description, its relationship to specific project requirements and its association with verification and validation testing. Depending on the size of the software project, the table may be expanded to include columns that show associations with other elements that may be involved with a given requirement (interfaces, external systems, other modules). • Change control involves the documentation of any and all changes made to requirements and thus provides a paper trail for any changes made to a system. This paper trail will include what changes were made, why, the original state, the changed state, the identifying label of the requirement being changed, who made the change(s), and when those change(s) were made (ideastub, 2014). Change control goes hand-in-hand with version control. As changes are made to a document the convention is to update the version number to reflect a more recent version of the software. In this way, the version number becomes another metric for tracking a software project throughout its lifecycle. Use of REQM to produce Metrics

  11. Requirements management provides a framework for developing, maintaining, improving, and reusing software throughout the software development lifecycle. • By implementing techniques that allow for traceability, version control, change control, and testing: software projects can be made more readily maintainable, easier to change or enhance, and portable across differing platforms. Summary

  12. Bezroukov, Dr. N.(1996-2014).A Slightly Skeptical View on CMM Softwarepanorama.org : http://www.softpanorama.org/SE/CMM/index.shtml • Bezroukov, Dr. N., et. al.(2014).Software Life Cycle Models.Softpanorama.org http://www.softpanorama.org/SE/software_life_cycle_models.shtml • Carnegie Mellon(2014).Capability Maturity Model Integration.Carnegie Mellon: Pittsburgh, PA http://www.tutorialspoint.com/cmmi/ • Hartman, K.(2013).CMM & Organizational Process Maturity.Kenneth G. Hartman, CISSP:Madison, WI. accessed online: http://www.kennethghartman.com/cmm-organizational-process-maturity/ • ideastub(2014).aNimble Platform.SourceForge, Dice Holdings, Inc: Urbandale, IA. http://sourceforge.net/projects/nimble/ accessed online • Jose, C.(2014).CS455 Requirements Engineering SRS template.CTU:Colorado Springs, CO References

  13. Magee, S.(2008).The Expert on ISO/IEC 12207 Software Lifecycle Processes.SEPThttp://www.12207.com/ • Moore, J.(2010).ISO/IEC/IEEE 15288 and 12207: The Entry-Level Process Standards.The Mitre Corporation http://www.ieee-stc.org/proceedings/2010/pdfs/JWM2677.pdf • SEPT(2009).ISO/IEC 12207 Checklist.Software Engineering Process Technology http://global.ihs.com/doc_detail.cfm?rid=SEPT&document_name=ISO/IEC%2012207%20CHECKLIST* accessed online • Software Engineering Standards Committee(1998).IEEE Recommended Practice for Software Requirements Specifications, Std 830-1998.The Institute of Electrical and Electronics Engineers, Inc.: New York, NY References (Continued)

  14. Software Engineering Standards Committee(1998).IEEE Guide for Developing System Requirements Specifications, Std 1233a-1998.The Institute of Electrical and Electronics Engineers, Inc.: New York, NY • Wiegers, K. & Beatty, J.(2013)Software Requirements 3, 3rd Edition. Microsoft Press:Redmond, WA., ebook accessed online ISBN 978-0-7356-7966-5 References (continued)

More Related