CSDP Driven

I did mention that I have a high regard for Tom Gilb. He has a technique that I think is valuable, and as with all techniques, can be adapted to fit anyones environment. I created a presentation – Evolutionary Requirements Engineering. Here are is a definition of a requirement:

A requirement is a stakeholder need that a developer is planning to satisfy.
A stakeholder is any person, group or object, which has some direct or indirect interest in a system.

I created this presentation from resources provided by Tom at a conference I attended. I think the concept of stakeholder is known by everyone, but do you know who are the critical stakeholders for your project? Accordingly, you must consider the entire life-cycle and identify the different categories of stakeholders.

Another concept is that you must analyze the requirements you gather. It is important to distinguish the ends (requirements) from the means. – ‘Means’ are the design ideas we choose: the architecture, technology, strategies and other synonyms (They are whatever is needed to achieve the requirements). Identify the key requirements that have the greatest impact on your most critical stakeholder values and system costs. And these key requirements could be decomposed into more elementary ones.

Now that you have identified your critical stakeholders and key requirements, how do you know you have met the goal of the requirement? Here again Tom gives us a technique to apply to our development: quantification. Here is Tom’s Simplified Quantification Procedure.

P1: Make sure you are dealing with an ‘elementary’ variable.

P2: Describe the ambition level.

P3: Generate a corresponding Scale of measure.

P4: Specify Conditions

P5: Specify a Meter.

P6: Try out the Scale.

P7: Repeat process until you are satisfied

P8: Generalize the Scale with more Parameters.
For more details check out the resources at Tom’s website on “Evo”, Evolutionary Project Management & Product Development.

Allen

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.

Allen

UPDATE:

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