Software Requirements

The second knowledge area is one of the first tasks in a project. Yet many people, those of the waterfall persuasion, may think that requirements work is finished when the coding starts. I’m sure that like testing, many managers think it is expendable when the project becomes time or funding constrained. However, a Professional should know that requirements need to be maintained/updated and tested against during the whole project life cycle. As with everything there are different classes and types of requirements.

Searching for a definition of Software Requirements, I start with “Software Requirements Engineering, Second Edition, Edited by Richard H. Thayer and Merlin Dorfman, published by the IEEE Computer Society Press in 2000 “. In the Introduction to Tutorial, the following definitions are found;

Software Requirements Engineering is the science and discipline concerned with establishing and documenting software requirements. It consists of: Software Requirements Elicitation, Analysis, Specification, Verification, and Management. Further, System Requirements Engineering is the science and discipline concerned with analyzing and documenting system requirements. A System can be considered a collection of hardware, software, data, people, facilities, and procedures organized to accomplish some common objectives. In software engineering, a system is a set of software programs that provide the cohesiveness and control of data that enables the system to solve the problem.

So those are the tasks involved, but what is the definition of a requirement? In the What is A Requirement? paper in “Software Requirements Engineering, Second Edition”, we find this: If it mandates that something must be accomplished, transformed, produced, or provided, it is a requirement – period. That paper continues on to explain the qualifiers – characteristics and relationships – attached to requirements.

The collection of papers in this book helps the software engineer with the processes involved around requirements. Again, I strongly refer everyone to Tom Gilbs book: Competitive Engineering, as well as his other resources at his web site. He states a number of fundamental concepts for systems engineering that are applicable to our discussion;

Clear communication amongst the different stakeholder groups is essential.

In any system, there are several Critical Success Factors. They include both performance requirements (such as serviceability, reliability, portability and usability) and limited resource requirements (such as people, time and money).

The primary systems engineering task is to design and deliver the best technical and organizational solutions, in order to satisfy the stakeholdersÂ’ requirements, at a competitive cost.

His Planguage2 (the specification language and methods described in his book) supports all of his concepts with practical ideas and methods. His book has a number of practical strategies for good projects to adopt, and I recommend everyone should obtain a copy.

Next time we will continue our discussion with requirements.



The SWEBOK identifies seven sub-areas;

  1. Software Requirements Fundamentals
  2. Requirements Process
  3. Requirements Elicitation
  4. Requirements Analysis
  5. Requirements Specification
  6. Requirements Validation
  7. Practical Considerations

Leave a Reply

You must be logged in to post a comment.