14

Click here to load reader

Colorado Technical University CS455 Jack Simmonds Instructor: Crispin Jose 5/4/2014

Embed Size (px)

Citation preview

Page 1: Colorado Technical University CS455  Jack Simmonds  Instructor: Crispin Jose  5/4/2014

SOFTWARE REQUIREMENTS MANAGEMENT

Colorado Technical University CS455 Jack Simmonds

Instructor: Crispin Jose 5/4/2014

Page 2: Colorado Technical University CS455  Jack Simmonds  Instructor: Crispin Jose  5/4/2014

TOPICS OF DISCUSSION

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

Page 3: Colorado Technical University CS455  Jack Simmonds  Instructor: Crispin Jose  5/4/2014

SUMMARY OF IEEE 830 & 1233 STANDARDS

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.

Page 4: Colorado Technical University CS455  Jack Simmonds  Instructor: Crispin Jose  5/4/2014

IEEE SUMMARY CONTINUED

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.

Page 5: Colorado Technical University CS455  Jack Simmonds  Instructor: Crispin Jose  5/4/2014

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

Page 6: Colorado Technical University CS455  Jack Simmonds  Instructor: Crispin Jose  5/4/2014

PURPOSE OF REQM WITHIN CMMI

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.

Page 7: Colorado Technical University CS455  Jack Simmonds  Instructor: Crispin Jose  5/4/2014

REQM WITHIN CMMI (CONTINUED)

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)

Page 8: Colorado Technical University CS455  Jack Simmonds  Instructor: Crispin Jose  5/4/2014

REQM GOALS & PRACTICES USED FOR CS455

Traceability Usability Maintainability Version control Security constraints Performance Reusability Verification & Validation

Page 9: Colorado Technical University CS455  Jack Simmonds  Instructor: Crispin Jose  5/4/2014

IDENTIFICATION OF A REQUIREMENTS MANAGEMENT TOOL

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.

Page 10: Colorado Technical University CS455  Jack Simmonds  Instructor: Crispin Jose  5/4/2014

USE OF REQM TO PRODUCE METRICS 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.

Page 11: Colorado Technical University CS455  Jack Simmonds  Instructor: Crispin Jose  5/4/2014

SUMMARY

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.

Page 12: Colorado Technical University CS455  Jack Simmonds  Instructor: Crispin Jose  5/4/2014

REFERENCES 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.orghttp://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

Page 13: Colorado Technical University CS455  Jack Simmonds  Instructor: Crispin Jose  5/4/2014

REFERENCES (CONTINUED)

Magee, S.(2008).The Expert on ISO/IEC 12207 Software Lifecycle Processes.SEPT http://www.12207.com/

Moore, J.(2010).ISO/IEC/IEEE 15288 and 12207: The Entry-Level ProcessStandards.The Mitre Corporationhttp://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 RecommendedPractice for Software Requirements Specifications, Std 830-1998.The Institute of Electrical and Electronics Engineers, Inc.: New York, NY

Page 14: Colorado Technical University CS455  Jack Simmonds  Instructor: Crispin Jose  5/4/2014

REFERENCES (CONTINUED)

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 Requirements3, 3rd Edition. Microsoft Press:Redmond, WA., ebook accessed online ISBN 978-0-7356-7966-5