| 
Requirements and Analysis Print

...or, the Other Pipe Dream!
In a thread in the Requirements Management forum ("do you prefer Word interface or separate application?") I responded with my definition of Requirements Engineering. My basic thoughts have not changed much, but I wanted to extend them somewhat and show more of CM's involvement in the Requirements process.

I have been involved in the software industry, formally and informally, for over three decades. In that time I have had to do Requirements Elicitation, Requirements Capture, Requirements Analysis, Requirements Normalization, Requirements Traceability, and Requirements Management. I have used ASCII documents, Word documents, Third-party hardcopy documents, Databases of one flavor or another, and various proprietary tools. Here is my take on all of this...

What Is Requirements Engineering?
Requirements Engineering consists of multiple roles, responsibilities, skills, tools, etc. The following is my take on how this breaks down.
  • Requirements Elicitation: The mechanism of prying the actual requirements from their source. This is often undertaken by such various activities as dialog, meetings, email, and RFCs. The skills involved are primarily being able to ask the right questions and hear the real answers.

    CM has no participation in Requirements Elicitation unless the discussion is about CM tools, policies, processes, procedures, etc.

  • Requirements Capture: The mechanism of taking the elicited requirements and creating the initial Requirements set. Note that I did not say document, though that is generally the form the both the source (client, customer, whatever) and other stakeholders expect and understand. A document by itself is a poor choice for the Requirements Engineer. Many people feel that Use Cases, Scenarios and the like can constitute requirements. I disagree. These are soft tools used in the Requirements Elicitation process and while being able to satisfy them may be a requirement of sorts, they are too complex to be requirements in and of themselves (see my definition of a requirement below).

    At this point, CM is involved in versioning the requirements as they are developed. While the tools may differ from what is used by Development, the requirements for tools do not. Each requirement needs to be versioned independently if possible and if not, then the "document" including them should be checked in often to keep the number of incremental changes small. While branching and merging is rarely possible, the use of change sets, electronic signatures and tags is not.

  • Requirements Analysis: The process of deriving secondary and implied requirements, determining and resolving conflicting requirements, assessing risks and cost of achieving (meeting) the requirements, etc. This also involves determining early which requirements are subjective instead of objective, and which requirements are not subject to testing or "proof."

    This requires an attention to detail, an overall knowledge of the application to be developed or modified and the ability to accurately access risk factors. Since most projects rarely use the classic Waterfall implementation model these days, it is generally at this phase that requirements are identified as to which point release they will go into effect (and which point release they will become obsolete in). This is the step most often skipped in practice once the base requirements have been captured as it only shows a return on investment (ROI) when a project starts to get complicated or the potential for customer-vendor disagreement is high. The result of the analysis process is normally not a document, but rather a list of individual requirements that can be traced.

    CM has no direct participation in this phase other than the continued support of the requirements versioning process and tools.

  • Requirements Normalization: The process of removing duplicate requirements, separating complex requirements into simpler "atomic" requirements, and adjusting the type each requirement (Business, Technical, Functional, Usability, etc.). It is also the phase where requirements are grouped together to provide a framework for design. The skills required are similar to those for Requirements Analysis with the addition of a knowledge of the business needs of the vendor and some experience in how the grouping and presentation of requirement to Design will affect the resulting Design.

    CM has no direct participation in this phase other than the continued support of the requirements versioning process and tools.

  • Requirements Traceability: The establishment of the initial traceability matrix and the subsequent management of it as development proceeds. The end goal of this traceability matrix is to show that all of the requirements have been met at project end. At a minimum, this should trace each requirement to some mechanism to "prove" that it has been satisfied. It may do this by tracing through development artifacts, but that is more of a QA/QC/Development/Management issue than a Requirements Engineering one. The skills involved in this are more the ability and desire to be a nitpicking pain and the ability to keep a large view of the details of the project in mind.

    At this point, CM is involved in versioning the traceability matrix as it is developed. While the tools may differ from what is used by Development or indeed the individual requirements defined above, the requirements for tools do not. Each line item in the matrix needs to be versioned independently if possible and if not, then the "document" including them should be checked in often to keep the number of incremental changes small. Like captured requirements, branching and merging of a matrix is rarely possible, though the use of change sets, electronic signatures and tags is.

  • Requirements Management: This is where I differ the most from my previous response. The actual management of the requirements and traceability matrix come into play at this point. Inputs are taken from both Development and Quality Control (QC) to update the matrix. Requirements may be "fine tuned" based on implementation issues and they may be highly modified based on scope creep and major problems encountered during implementation. This role also provides oversight to ensure the design and implementation phases meet the intention of the requirements as well as the letter of them. This means that even in a classic Waterfall implementation model, Requirements Management is a role that extends to the completion of the project.

    CM's role during this phase is to continue the control of the physical requirements repository and the enforcement of classic CM Version Control and Release Management rules on each individual requirement and on the traceability matrix.
What Is a Requirement?
 Now that we have covered the basic definitions, roles, etc. just what is a requirement? A requirement is a statement that is unambiguous, simple (versus compound) and testable. It normally uses words like "shall" and avoids words line "will" or "should." Being unambiguous is somewhat subjective as readers of the various CMCrossroads forums can attest. The more we try to nail down language, even to the point of defining a syntax and grammar all our own, the more we tend to confuse both ourselves and others. There will always be some level of connotation involved in the language describing a requirement. Requirements should not make multiple statements such as, "the transaction processing subsystem shall be able to execute 1000 transactions per second and display a running status dashboard of them in real time." Not only does this present testability and traceability problems, it tends to send Design down the wrong path by artificially coupling the two base requirements. And finally, requirements should be objectively testable. Statements like, "the User Interface shall update at an appropriate rate," is open to interpretation by both the Development group and the end customer. Most likely they will each define "appropriate" to their own advantage.

It should be understood that there will be some fuzzy requirements just because that is the best that can be done with them. They should, however, be in the minority.

What Form Should Requirements Take?
As I said earlier, most end-users and stakeholders want to review and approve requirements based on some form of documentation. This is just the way they think and the way most of them were taught. It can also be thought of as a common denominator between the various audiences. This implies that regardless of how the requirements are maintained internally starting at the Requirements Analysis phase, they will have to produce a document from them that is provably the same as the requirements they are maintaining internally.

There are a few tools on the market that attempt to make a bidirectional translation from a requirements document to a requirements matrix and back to an updated document, but most of the vendors admit that it doesn't really work well unless you want a hierarchical list of bullets or have active links into a document for every requirement in the matrix. This last is where the problems start as is the function of the Analysis and Normalization phases to break these requirements down, rearrange them, etc.

It has been a few years since I had to actually use Requisite Pro, but I remember that it could take a Word document and import a requirements "base" from it. Maintenance going forward was more difficult and often resulted in having to play major games with the Word document to keep it "looking nice." Regardless, at the time I thought it was the neatest thing since sliced bread. Notice that I started with a document, captured the requirements, and then went into a maintenance mode. I skipped a lot of the steps of Requirements Engineering that I went through earlier, but then the project was of a manageable complexity and only had one iteration.

On another project, I started with having to go from one stakeholder to another performing verbal Requirements Elicitation, capturing the requirements as I went along. I then had to reconcile them, normalize them, etc. Then I had to create a working document that would be used to negotiate the final requirements set along with which release each requirement would have to be implemented by. I used a database to store the individual requirements that would version each of them as they were updated, and that would allow them to be grouped together in various ways. Using that to manually produce a document was painful. Updating them based on changes to the document was even more so, but this was considered part of the Management role and could not be avoided. The expression on the reviewers faces if I had presented the database / matrix itself instead of a document, however, would have been priceless.

Summary
  • Requirements need to be individually versioned and "released." They should be kept internally either in a tool that does this or in a database where the versioning is programmed to automatically occur. A spreadsheet is a poor man's method of accomplishing this, but is not suitable for large requirements sets.
  • If the requirements are captured from, and intended for review by, technical people that can understand line-item and or matrix presentations of requirements, then this method is least ambiguous.
  • If the requirements need to be reviewed by people who need documentation, then documentation should be supplied.
  • If documentation is generated from a requirements tool or database, then it should be done so automatically or programmatically. Manual generation should be a last resort.
  • A fully integrated tool is the best of all worlds.
I have said in various threads that I consider Requirements Management a part of CM. I have always meant, but may not have been clear, that Requirements Management is used in the above sense. CM may not do the actual job if Requirements Engineering exists, however they are responsible setting the minimum requirements for CM compliance. I have also said or implied that the Requirements Traceability role is a part of CM, but what I really meant is that the role may be delegated to CM since they often "own" both the tools and data necessary to do the job.

Why do I consider this a pipe dream? Because unless it is understood by Management going into a project that either they cannot avoid doing Requirements Engineering/Management or the project is going to be controversial and agreement between vendor and customer is needed to keep from getting into a constant rework situation, then requirements are often skipped or treated informally. Lacking clear requirements, Design will base their deliverables more on what they want (or want to do) rather than what the customer expects. This in turn can lead Development into spending time and money on something the customer may reject when they get a good look at it. QC, lacking clear requirements, can only test for technical faults and subjective feel. Good requirements cost money, time and resources that may not be available.

Ben Weatherall is currently based in Fort Worth, Texas where he practices Practical CM on a daily basis using a combination of CVS and custom tools to support a modified Agile-SCRUM development methodology. He is a member of IEEE, ASEE (Association of Software Engineering Excellence – The SEI’s Dallas based SPIN Affiliate), NTLUG (North Texas Linux Users Group), and PLUG (Phoenix Linux Users Group).
Trackback(0)
Comments (0)add comment

Write comment
smaller | bigger

security image
Write the displayed characters


busy
 
[ Back ]

Video News