Requirements gathering is an essential part of any project and project management. Understanding fully what a project will deliver is critical to its success. This may sound like common sense, but surprisingly it’s an area that is often given far too little attention.
A key element of any project is understanding the customer requirements. This is where the Unified Modeling Language (UML) can help.
A critical part of any software development project is the requirements gathering. If you are unclear about what is going to be delivered, how will you know when you get there? Good user requirements lead to better estimates, improved customer satisfaction, reduced cost and a shorter duration.
The Rational Unified Process, Enterprise Unified Process, Agile Development Methodologies, Unified Modeling Languages. They come in many names, complexities and sizes but following one will help ensure success on your next project. This is not a detailed overview of a formal process. Instead it provides an overview of the most critical components common to each, as well as some tips on successfully deploying them.
Recently, I attended a class on managing requirements with Use Cases. It was aimed at training business analysts and programmers to use Unified Modeling Language (UML) to understand and communicate business requirements. As a project manager I found it both enlightening and encouraging.
The RASCI model helps to clarify responsibility assignment. It is used in project management to identify roles and responsibilities during the projects.
The RASCI model uses the following profiles
- Responsible: It’s is the person who is owner of the project
- Accountable: It’s the person to whom « R » is Accountable and is the authority
- Supportive: He provides resources or plays a supporting role in implementation
- Consulted: He provides information and/or expertise
- Informed: He needs to be notified of results but need not necessarily be consulted
The RASCI model is primarily the cornerstone for devising an ideal communication plan during project implementation. The « Consulted » role signifies the two-way communication typically between « R » and « C ». The « Informed » role signifies the one-way communication primarily from « R » to « A » .