Requirements Elicitation using a workshop

By Katlego Raboshakga

Analysts have a number of techniques at their disposal to enable them to perform requirements elicitation. These techniques can be used concurrently to get a comprehensive set of requirements. One of the common elicitation techniques often used is the requirements elicitation workshop.

According to Schalken, Brinkkemper and Van Vliet, “Facilitated workshops are intensive meetings in which technical staff, end-users and management collaborate on information systems development tasks such as project planning, requirements specification and user interface design. It is clear from this definition that requirements workshops entail a lot more than just eliciting requirements. Workshops focus on the system development project in its entirety and involve stakeholders from different backgrounds. This team of stakeholders often consists of the project sponsor, subject matter experts, representative users, the scribe and observers.

Requirements elicitation workshops should be led by an unbiased and experienced facilitator, with exceptional facilitation and communication skills. The role of the facilitator is to manage the meeting and keep the team on track as well as facilitate a process of decision and consensus making amongst other things. The facilitator has to do extensive planning of two to five days prior to the workshop to ensure that it achieves its objectives.

Some of the benefits of requirements workshops as stated by Young are that it is a “dynamic, interactive and cooperative process and it involves users and cuts across the organizational boundaries”. Contentious issues can be resolved quickly and when properly run they manage user’s attitude towards change as well as user expectations. Workshops also create a suitable environment for applying other elicitation techniques such as prototyping, requirements gathering with use cases and role playing.

The success of a requirements workshop depends on a few critical factors such as executive commitment, reasonable scope, participant commitment and preparation and equal participation. If correctly executed a requirements elicitation workshop will contribute immensely to the requirements definition and management process and to the ultimate success of the system development project.

References

Schalken J., Brinkkemper S., And Van Vliet H., Assessing the Effect of Facilitated Workshops in Requirements Engineering, Available from http://www.cs.vu.nl/~joost/publications/2004AssessingtheEffectsofFacilitatedWorkshopsinRequirementsEngineering.pdf, (Accessed 9 September 2009)

International Institute of Business Analysis, A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 2.0

Young R., Recommended Requirements Gathering Practices, Available from http://www.clearspecs.com/downloads/ClearSpecs58V01_Recommended%20Reqts%20Gathering%20Practices_Young.pdf, (Accessed 10 September 2009)

Requirements Elicitation - Part 2

By Katlego Raboshakga

Requirements elicitation forms the foundation of any software development project and this process often comes with a lot of problems. These problems are often not fully addressed or resolved and this results in them running into the subsequent phases of systems development with the result being that the system does not meet user expectations. The means of executing elicitation activities and iterating between them is unfortunately still not thoroughly understood.

According to Christel and Kang, requirement elicitation problems can be categorized into three groups: problems of scope, in which requirements either go beyond the scope of the project or do not address the entire scope; problem of understanding between the project team and users and the problem of volatility, which is the changing nature of requirements. These problems are further perpetuated by the lack of sufficient communication between the stakeholders involved and the analysts.

To address the problem of scope, the analysts must focus on the analysis of the organisation as well as the objective of the system. This will give them an idea of where the system fits in the organisation as well as what the system hopes to achieve.

Communication is the key to addressing the problem of understanding. The analysts need to be aware that stakeholders come from different backgrounds and therefore will have a different understanding of the concepts used. All issues must be properly articulated until consensus is reached.

As requirements change, the elicitation process should be revisited to address the evolving requirements and to make sure that the system is aligned to these evolving user needs.

The problems mentioned above are only some of the many problems in requirements elicitation. Other elicitation challenges include the stakeholders’ unwillingness to change to a new product, unspoken or assumed requirements, limited time and many more. Selecting the right techniques and encouraging continuous communication can help to mitigate many of the elicitation problems encountered.

References:

Christel M., And Kang K, Issues in Requirements Elicitation, Available from http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf, (Accessed 25 August 2009)

http://ezinearticles.com/?Challenges-in-Requirements-Elicitation&id=1901199, (Accessed 01 September 2009)

http://faculty.kfupm.edu.sa/ICS/elish/files/Chapter8_The_Challenge_of_Requirements_Elicitation.pdf, (Accessed 03 September 2009)

Requirements Elicitation - Part 1

By Katlego Raboshakga

Requirements elicitation is regarded by many IT practitioners as the first step in any systems development project. The success or failure of any computerized system depends on how well this process is undertaken, amongst other things. Simply put, requirements elicitation is the process of getting the requirements of a system from the user community and other stakeholders. According to Christel and Kang, requirements elicitation is ““the process of identifying needs and bridging the disparities among the involved communities for the purpose of defining and distilling requirements to meet the constraints of these communities”

Within the requirements elicitation process there are a few key activities that have to be performed. These activities include but are not limited to, defining the product vision and project scope, identifying customers, stakeholders and users, selecting product champions and choosing elicitation techniques. In eliciting the requirements the analyst has to ensure that the requirements are consistent and feasible and also has to validate them to ensure that they are an accurate reflection of the user’s needs. Requirements elicitation is an iterative process that takes place throughout the development life cycle and in this way changing and new emerging requirements are taken into account.

As mentioned above one of the primary activities of requirements elicitation is choosing a technique or a number of techniques that will optimally enhance the requirements gathering process. Some of the more common techniques are brainstorming, document analysis, focus groups, interviews, prototyping and requirements workshops. Thorough preparation has to take place before any of these techniques can be used. Detailed schedules have to be compiled and all the necessary resources should be properly organized to achieve the best results.

Finally, once the requirements are in place a CASE tool should be used to document them. This documentation should be updated as and when the requirements change. The analysts must ensure that there is good communication between them and the stakeholders to ensure that any other requirements are not left out.

References

Christel M., And Kang K, Issues in Requirements Elicitation, Available from http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf, (Accessed 25 August 2009)

Borland (May 2009), Effective Requirements Definition and Management

International Institute of Business Analysis, A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 2.0

What is requirements definition and management

By Katlego Raboshakga

Requirements definition and management are subsets of software engineering as it is practiced in the context of the development of a software system which aims to fulfil the needs of the stakeholders. It is a very intensive human interaction process and therefore needs to take into account the way the stakeholders perceive their surroundings, their work and how they interact within the workplace.

Requirements definition and management borrows some of its techniques and practices from the social sciences. It takes into account aspects such as cognitive psychology, anthropology, sociology and linguistics. These all aim to explain the human behaviour. It is extremely important to take these factors into account as the dynamics of the stakeholder team often vary extensively. Understanding human behaviour and characteristics gives the analyst the fundamental tools to perform requirements management optimally.

According to Nuseibeh and Easterbrook, requirements elicitation is often regarded as the first step in requirements management. Several techniques such as workshops, prototyping, brainstorming and interviewing are applied in combination to enable optimal requirements elicitation. Once these requirements are obtained and understood commitment has to be obtained from the stakeholder and these requirements have to be sufficiently documented. Other subsequent activities in requirements management include, but are not limited to, managing requirements changes, maintaining traceability of requirements and identifying inconsistencies between the deliverables and the requirements.

The human interaction aspect involved in requirements management forms the cornerstone of all system development projects. Although the end result of a system development project is usually a computerized system, its primary function is to address the needs of the stakeholders. A computerized system that does not address the stakeholder needs is a complete failure. Ultimately the success or failure of a system will be determined by whether the stakeholders perceive it to meet their requirements or not.

References

Nuseibeh B., And Easterbrook S, Requirements Engineering: A Roadmap, Available from http://www.cs.toronto.edu/~sme/papers/2000/ICSE2000.pdf, (Accessed 19 August 2009)

CMMI for Development version 1.2, Improving processes for better products, Available from http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html, (Accessed 19 August 2009)

Avison D. And Fitzgerald G. (2006), Information Systems Development, Methodologies, Techniques and Tools 4^th Edition, McGraw-Hill

Requirements Definition and Management

By Katlego Raboshakga

Many software development projects of today are still plagued by delays, running over budget and at times even creating systems not useful to stakeholders.

According Oberg, Probaso and Ericsson, the most often neglected factor, in successful system delivery, is the mismanagement of user requirements. They define requirements management as: “a systematic approach to eliciting, organizing and documenting the requirements of the system, and a process that establishes and maintains agreement between the customer and the project team on the changing requirements of the system.”

It is clear from this definition, that for projects to have a higher probability of success, these activities need to be carefully planned, coordinated and executed. The right techniques, tools and people have to be applied at all stages of the requirements management process to minimise the chances of getting undesirable results.

Throughout a system development project, from user requirements elicitation to system implementation, requirements change. To manage and control requirements change in a smooth and manageable fashion, the business analyst has to ensure that constant communication and consensus on the requirements between all the stakeholders are facilitated.

This has the implication that the business analyst has to be an excellent communicator, as the process of requirements definition is rich in person to person and group communication and negotiation. Any misunderstandings between stakeholders and the business analyst, or between analysts and developers will inevitably result in a system that does not satisfy the stakeholders.

New requirements and changes to existing requirements should be proactively monitored and impact assessments done on the baseline requirements. Unbridled requirement changes often significantly impacts on the system delivery life cycle, and project resource requirements.

References:

Borland (May 2009), Effective Requirements Definition and Management

Oberg R., Probaso L. And Ericsson M., Applying Requirements Management with Use Cases, Available from http://www.sos-portals.com/Interesting%20Articles/Manage%20Requirements/RUP_AppReqMgmt.pdf, (Accessed 14 August 2009)

Kimball R., Reeves L., Ross M. And Thornthwaite W. (1998), The Data Warehouse Lifecycle Toolkit, Practical Techniques for Building Data Warehouse and Business Intelligence Systems 2^nd Edition, Wiley