Monday, August 31, 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

Tuesday, August 25, 2009

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 4th Edition, McGraw-Hill

Thursday, August 13, 2009

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 2nd Edition, Wiley