Developing and Implementing Testable Requirements

 

Requirements

The word says it all.  Requirements- Must Haves.  What is required for the applications to run properly?  What is necessary in order to make the application successful? Do all the participating people understand what the client’s expectations are?  Or do we just assume we know what they want and proceed with that misunderstanding?

Client’s Needs

Does the client really understand what they need?  Will they be changing their minds as we go along?  Do they have a clear understanding of what the final product should do?  Not always.  This is often demonstrated by Creeping Scope.  Creeping Scope is what happens when client’s needs are not clearly understood before the project begins.  Unfortunately, clients do not always know what they need, but they have a long list of things they would like to have.  But how much of what they would like to have are really necessary to make the project successful?  How do we define success?  Doing everything the client wants?  That is almost impossible.  What is really necessary is to clearly understand what they client needs.  These needs are not always evident to all the participants.  So we need to better understand what we have to do.

Needs Analysis

The purpose of a Needs Analysis is to separate the “needs” from the “wants.”  The client may want more than what is available, have the money for, can be done within the time frame, etc.  The Business Analyst is chartered with interfacing with the client and discussing the client’s needs.  This discussion will lead to the specification which summarizes the results of those discussions.  However, the specification is normally written in the client’s language so the client will sign off on the document.  But how many other people in the organization speak the client’s language?  Few if any. Thus there must be a process in place to clarify for each participant exactly what their roles will be in the project.  That is done during the Needs Analysis.  Who should attend?  Anyone that is responsible for the success of the project.  Project Managers, Business Analysts, Programmers, Testers, Quality Assurance, Clients, etc...  It is very likely that the specification will change as a result of this process, so no design, code, etc., should be started until the Needs Analysis and the walk-thru is finished.  “This takes time and we don’t have the time.”  Sound familiar?  What makes more sense, knowing what needs to be done before the start, or trying to fix it up later on because we didn’t fully understand what they client meant in the first place?

Business Requirements

Since the specification is written in the client’s language, there is a need from the very beginning to convert the client’s language into the language of the development group and the testing group.  Here again we have different needs for understanding.  The programmers have to understand how they will make the application run on the system.  The testers have to understand how they will prove it meets the user’s needs.  Testers don’t care what language the program was written in, all they are concerned with is does it meet the user’s needs?  So they have to understand what the user expectations are and how they will use this application in their environment.  Two entirely different needs, yet are they?  The overall objective is always to deliver a product that is going to satisfy the client.  How can this be done if there is confusion from the very beginning on what those expectations really are?

Walk-thru

What is a walk-thru?  Many people in the organization are currently doing walk-thrus within their own groups.  Design walk-thru, code walk-thru, etc... But how many do a walk-thru of the specification, or a walk-thru of the requirements? How many times are their questions as to what the client meant versus what they said?  How many misunderstands happen because too many assumptions were made?  Since the specification is written in the client’s language we need to break it down into a language clearly understood by the development group and the test group.

Reverse Presentation

One of the best ways to ensure understanding is to use graphics to complement the text.  Most people can understand graphics more easily than trying to interpret what someone meant to say.  Do a reverse presentation.  A reverse presentation is when the development team explains back to the client their understanding of what the client said in the development teams own words.  This reinforces the understanding between the two parties that everyone is in sync.  By doing this up front, prior to design, a clearer understanding should result. This incidentally, will make better use of time and resources and will help prevent late deliveries and save money on development and maintenance.

Now that the walk-thru is complete, and it could take many walk-thrus, it is probable that we will need to change the specification to match the requirements. This is why no design or coding should be done till the walk-thrus are completed.  If any design had been done, it may have to be redone to match the new understanding of the requirements.

Designing the system from the business requirements

Now everyone should be on the same page.  The programmers have a clearer understanding of what the client expects, and how they will use it.  The testers can now design and develop scripts and test cases to emulate the client’s environment.  The application should be designed, coded, and tested in accordance with the user’s expectations.  Creeping scope should be eliminated or at least reduced.  Rework should be kept to a minimum.  Time and resources will be maximized.  Sound too good to be true?  Well it isn’t when proper process and standards are designed and implemented.

Who is responsible for the Business Requirements?

Maybe the questions should be who is responsible for ensuring the business requirements are clearly understood?  That responsibility belongs to the Business Analyst.  Unfortunately not all organizations have Business Analysts, and therefore the responsibility seems to drift around and no one accepts the role.  As a result more time and money are wasted because there are no standards or processes in place.  In some organizations the responsibility ends us with Quality Assurance.  There must be some group or person that will have the final say on acceptance to changes, and that should be the BA.

But the BA cannot do it all by themselves.  They need the cooperation of all the team members to ensure buy-in.  Without this cooperation some team members will be going in the wrong direction and may not be found out till it is too late to change, or worse yet, end up with customer dissatisfaction or product rejection.  The process of the Needs Analysis, the Walk-Thru, and the Reverse Presentation should be identified and repeated from project to project.  This is where the QA group comes in.  They do not design process in a vacuum, but solicit input from all as to how is the best way to do it.  Then they incorporate these ideas and make them a standard.  Then they enforce the standard.

Teamwork

 

The key to success is teamwork.  But teamwork does not just happen.  It needs to be planned, monitored, and executed.  The Project Manager’s job is to ensure that everything that needed to be done has been done.  But how does the project manager know what needs to be done if we have failed to follow this process.  Crystal balls and Ouija boards are not good tools.  They may be amusing but the project is not trying to be entertaining, but wants positive results. 

Priorities

Everyone has their own ideas as to what is most important.  These ideas have to be reviewed and assigned prior to the beginning of system design.  The Critical Success Factors, (those features that must be done,) have to be identified and assigned priorities so milestone can be set and met.  There critical features must be in the system and others that are less important may be added in future releases.  All team members must be in agreement on what will be done and when it will be done.  How it will be done is not part of this discussion.  Each programmer has his/her way of implementing requirements.  This process just ensures that all requirements will be met. 

End Result

Since all team members now have a better and clearer understanding of what the client needs, the process for making it happen will be easier to implement.  These processes should be designed so they are repeatable and maintainable.  The process will stay the same, only the needs may change.  Templates can be designed and reused on subsequent projects.  This should result in saving time and resources in the future.  Everyone can benefit from lessons learned.