Software Engineering Processes

Linda Westfall

Traceability is one of the essential activities of good requirements management.  Traceability is used to ensure that the right products are being built at each phase of the software development life cycle, to trace the progress of that development and to reduce the effort required to determine the impacts of requested changes.  This article explores:

    What is traceability?
    Why is traceability a good practice?

    How is traceability performed?

Original: February 28, 2006

Revised: March 18, 2009

Scott Duncan

My involvement with standards, methodology and process issues brings me in contact with people who ask what agile methods are or what they are about.  Many have not heard of the Agile Manifesto and associated principles.  When I ask what they have heard about agile methods, I am told things like pair programming, no documentation, refactoring, iterative development, no planning, daily “stand-up” meetings, etc.  Of course, none of these get at the heart of what agile methods are “about” (beyond the fact that some are not true).

Based on listening to the creators of agile methods and reading what they have written on the subject, agile methods, above all else, seem to me to be about expanding the bandwidth and frequency of communication and about being open to change.  Essential to both of these is the existence of effective feedback, which is required for meaningful communication and productive change. The values, principles and practices of agile methods seem to flow from seeking to achieve these objectives.

Linda Westfall

If the software requirements aren’t right, you won’t end up with the software that you need.  The original version of this paper was presented by Linda Westfall at the World Conference on Quality and Improvement 2005.  The updated version was published in the ASQ's Software Quality Professional Journal.  This article discusses:

  • Why: the benefits of having the right software requirements
  • What: the various levels and types of requirements that need to be defined
  • Who: identifying the stakeholders of the software requirements and getting them involved in the process
  • When: requirements activities throughout the software development lifecycle
  • How: techniques for eliciting, analyzing, specifying and validating software requirements

Date Original Version Posted: May 7, 2005

Date Updated Version Posted: March 1, 2006

Scott Duncan

What’s the “right” method to use for a software development project according to all the “best practices” advice?  How would you answer this question or is this really a sensible question to ask?  Many folks advocating “lite” or agile methods would suggest there is no “best” practice you can apply across the board.  Articles and columns in IEEE and ACM publications have addressed this very point.  On the other hand, advocates of “disciplined” methods (to use the term Boehm and Turner have in their book on agile and more formal methods) would say there is vast industry experience pointing to “best practices.”  This paper, from Scott Duncan's presentation/discussion session at the 14th International Conference on Software Quality, is about beginning the process of answering some methodology related questions.

Agile Alliance -

Agile Project Leadership Network -

ASQ Software Division -

Association for Computer Machinery -

Crosstalk, The Journal of Defense Software Engineering -

Cyber Security & Information Systems Information Analysis Center (CSIAC) -

Dilbert -

Extreme Programming - (XP)

Extreme Programming (XP)-embedded -

Feature Driven Development -

IEEE - Institute of Electrical and Electronics Engineers -

IEEE Computer Society -

International Organization for Standards -

The IT Metrics and Productivity Institute -

Object Management Group, Unified Modeling Language (UML) -

Open Web Application Security Project (OWASP) -

Process Impact, Karl Wieger’s website -

Scrum Aliance -

SEI - Software Engineering Institute -

Software Program Managers Network -

Software Testing and Quality Engineering -

Software Assurance: Community Resources and Information Clearing House Sponsored by the US Department of Homeland Security Cyber Security Division -

SWEBOK - Software Engineering Body of Knowledge -

Wikipedia -

The Certified Software Quality Engineer Handbook, Linda Westfall, ASQ Quality Press, Milwaukee, WI, 2009.

Software Requirements, 3rd Edition, Karl E. Wiegers and Joy Beatty, Microsoft Press, Redmond, WA, 2013.

Mastering the Requirements Process: Getting Requirements Right, 3rd Edition, Suzanne Robertson and James Robertson, Addison-Wesley, Upper Saddle River, NJ, 2012.

Requirements by Collaboration, Ellen Gottesdiener, Addison-Wesley, Boston, 2002.

Writing Effective Use Cases, Alistair Cockburn, Addison-Wesley, Boston, 2001.

Capability Maturity Model Integration (CMMI) for Development, Version 1.3, Carnegie Mellon University Software Engineering Institute, Pittsburgh, PA, 2010, (available on the SEI website).

Software Architecture in Practice, 2nd Edition, SEI Series in Software Engineering, Len Bass, Paul Clements and Risk Kazman, Addison-Wesley, Boston, 2003.

Extreme Programming Explained: Embrace Change, 2nd Edition, Kent Beck and Cynthia Andres, 2004.

© 1999-2022 Westfall Team, Inc.