Shortening the Requirements Definition Phase on Your Project

Have you ever asked yourself why your requirements definition phase seems to take so long? On even short projects the definition phase can take as long as the implementation phase. Here are some suggested reasons why this may be the case.

1. Your elicitation sessions are unplanned and ad hoc. Planning your elicitation session and identifying key stakeholders is a key activity during requirements definition. Planning your sessions and setting them up ahead of time give stakeholders an opportunity to set aside the required time to both prepare and attend the sessions. Without this planning you may miss key stakeholders, requiring additional sessions to get their inputs.

2. There are too many attendees in the session. Have you ever attended a requirements gathering session with 15-20 people in the room? Have you asked why some of these people were providing requirements for a system they would never use? When you are planning your sessions identify key people who are required to attend. Keep the list to approximately 5-7 people. If additional people “show up” for the elicitation sessions, make it clear they are welcome to listen but that you are looking for input from the key stakeholders you identified. This is a great topic to discuss during the project kick-off as well.

3. The elicitation discussions quickly become revolved around technical and implementation issues. One of the key factors during elicitation sessions that can get you bogged down is focusing on how you are going to solve the problem versus just understanding the problem. Keep the discussion away from technical details and implementation solutions. Users will tend to lose interest in these discussions and you will lose valuable time.

4. The elicitation discussions wander off topic. Again, a key to preventing this is planning. Identify topics to be covered during an elicitation session and review them at the beginning of the session. Be a strong facilitator and keep the discussion on track. Identify a parking lot of items for later discussion versus sorting them out during the elicitation session.

Hopefully these suggestions will help guide your definition phase to a clear and timely conclusion.

By: Marcia Stinson

Word + Excel = Requirements Management?

Although MS Word and MS Excel cannot be seen as requirements management solutions, in practice many organizations use them to manage requirements. Why that?

Requirements are very often of textual nature, so taking a word processing tool seems obvious. In most cases MS Word is already installed and users are – more or less – familiar with it. Also, people still believe requirements must be structured by means of documents which are sometimes also requested by certain certification authorities.

But if you start categorizing your requirements in different ways, for example by priority, customer, country, product release, etc. you may find MS Word improper. Now MS Excel seems to be the better choice because attribute information can be added to the requirements in separate columns and you can even filter your requirements according to certain criteria, but unfortunately you lose the textual description and formatting capabilities.

Seems like a combination of MS Word and MS Excel is feasible to do requirements management. But: Have you ever tried to:

• Work in parallel on the same document?
• Find out who has done what changes and why?
• Find out which other information (more detailed requirements, test cases, …) in which other documents is affected by an upcoming change?

Find out which of the information in your document is potentially out-dated due to changes done somewhere else? Professional requirements management solutions provide quite a lot of additional capabilities, like

• logging the history of changes
• the ability to create and analyze relationships between atomic information items (requirements, use cases, test cases, …)
• suspect relations
• …

helping to ensure consistency in the requirements throughout a project.

Do you still think Word/Excel are feasible for requirements management? Share your view…

By: Andreas Plette

Your requirements are dynamic? – Keeping track of requirement changes

Professional requirements management solutions track in the background what’s happening in your project. What changes have been done and what’s remaining unchanged? Given the high granularity – each single Requirement is a database element – all changes are recorded on requirements level. This allows analyzing in detail which changes have been done between two versions of the same requirement. Who has done the changes and when? What exactly has the user changed? Is there any comment about the changes?

Professional requirements management solutions provide a build-in versioning mechanism. Before being able to modify a requirement or one of its attributes users need to “check out” the requirement. Once they’re done with their modifications they “check in” the requirement again. All the changes are recorded and can be visualized later using a “diff” between any two versions of the requirement.

Apart from keeping track of changes to single requirements professional requirement solutions do also allow visualizing the differences between two different baselines. A baseline is a snapshot of a selected set of requirements at a certain point of time defining a reference point for ongoing development.

Last but not least requirements management solutions help keeping your requirements consistent. Whenever you have to change a single requirement, all related requirements get suspect allowing users to easily identify all requirements that might be affected by a change done somewhere else.

By: Andreas Plette