Requirements Engineerig

After a two week diversion from normal activities to complete a Final Report on Uncertainty Quantification (UQ), I'm anxious to share thoughts with you on the topic of requirements engineering.  Systems engineering function and responsibility in the area of requirements engineering and management are critical and not to be taken lightly.  There are, however, some simple ideas surrounding the requirements engineering process.  I'd like to share some of those ideas fresh from our UQ requirements work.  In addition, I've recently supported the Very Small and Micro Enterprise Working Group (VSME WG) of the International Council on Systems Engineering (INCOSE) development of a draft Requirements Engineering Deployment Package.  This product seeks to provide requirements engineering process guidance for small organizations and teams.  The basic ideas from these experiences are shared below. 

One of the fundamental responsibilities and assets of the systems engineer is requirements.  In systems engineering practice, requirements engineering and management are critical to the success of projects.  Like so many other artifacts developed by systems engineers (Concept of Operations, Architectures, models, etc), requirements give us something to drive collaboration and understanding.  Requirements allow us to create the framework for a project, program or activity that serves as a basis (baseline), which can grow and change as we learn. The impact of requirements engineering on the success of projects is well documented.  The Standish Group Chaos Report reported that basic requirements is one of six main causes of project success at all levels. 

Requirements engineering focuses our thinking and gives us perspective on the project.  With system (project) level requirements we can have meaningful stakeholder discussion and discovery.  This discussion helps us move on to operations concepts, use cases, architecture and ultimately design.  There are detailed treatments on characteristics of good requirements, sets of requirements, rules and attributes that should be considered by the systems engineer during the requirements engineering process.  These policies and guides are useful in building expertise within an organization or team.  Use these resources as you evolve your requirements engineering expertise and practice. 

The good news is that requirements engineering doesn't need to be complicated.  Systems engineers should work with requirements routinely and re-visit them often for updates as necessary.  There are no wrong answers when it comes to requirements, just bad requirements that can serve better understanding when they are corrected.  Develop core competency in requirements engineering by doing the following:

• Start simple, but start.  
• Connect the team.
• Build upon success.

The requirements engineering process takes place throughout the life cycle of the project.  At the start, someone has an idea, need, or concept.  Requirements, or some notion of the client needs, are necessary before we talk about a concept or architecture to satisfy the client.  Here are a few sources of requirements for the systems engineer conducting requirements engineering for a new project:

1. The clients statement of need.  
2. Project context and operating environment. 
3. Client preferences and experiences. 
4. Scope of the project. 

Requirements drive design, and are typically provided to developers to build assigned components of the project.  Finally, testers use the requirements to establish verification that the requirements are satisfied.  Effective requirements engineering is an active process, and changes to requirements are inevitable.  

Requirements engineering is not an exact science.  We are uncertain about requirements and time spent understanding project requirements is essential to get clarity.  The systems engineer needs to ask questions, make assumptions, and capture ideas as they emerge into requirements.  Ask the client what they want, listen intently, and write it down.  You may have a description of how the "thing" operates, what it does, and how it does it.  This is an excellent source of early requirements in a project.  There is always a tendency to engineer the solution as soon as the first requirements are identified.  Resist this temptation by collecting requirements that start out with, "the system shall/will.."  Look for shall/will statements that describe:

1. Functions
2. Inputs
3. Outputs 
4. Interfaces

Share the growing list of system requirements with stakeholders.  Get stakeholder feedback and iterate, iterate, iterate.

 I'll share more on requirements in future posts.  Below are a few good references on requirements engineering:   

 References:

Software Engineering Institute Requirements Engineering and Analysis Workshop Proceedings

Requirements Engineering Wiki

ISO/IEC 15288:2008 Systems and software engineering -- System life cycle processes