SOFTWARE REQUIREMENTS MANAGEMENT

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
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.
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.
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).
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.
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)
REQM GOALS & PRACTICES USED FOR CS455
Traceability
 Usability
 Maintainability
 Version control
 Security constraints
 Performance
 Reusability
 Verification & Validation

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.
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.
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.

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.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/cmmorganizational-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 (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 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=I
SO/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)

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