Learn social networking for business best practices at the Social Networking Conference 2010 this April 22 and 23, 2010 at Hotel Intercontinental Makati City

The Requirements Analyst Role

by Janette Toral

(view photo gallery for a bigger image size)

In the requirements management phase of the software development lifecycle, the role is carried out by a person referred to as a requirements analyst or its counterpart. Scope of work requires skill in user interaction, documentation, data gathering, negotiation skills, team leadership, complete-cycle software development experience, among others to be able to perform the following task:

1. Talk to users and project proponents.
Data gathering can come in many ways such as use cases, workshop, video conferencing, prototyping, survey, meetings, document review, natural observation, and user interviews.

Preparation is important. If there are several options being considered and information is available, a comparative evaluation will also be performed.

After every meeting, minutes are prepared for concurrence with the client. Until sufficient information is gathered, drafting of documents, such as the Vision and Scope document (sometimes referred to as Project Charter), that shall serve as a preliminary agreement with the client, can’t proceed.

2. Document the requirements. The requirements analyst should be able to document the requirements in the following areas:

Business requirements stated by project sponsor. This shall serve as the ground work for the vision and scope of the project.
User requirements given by user representatives. This details the tasks that users must be able to perform with the new application. Quality attributes, like maintainability and usability, are noted here as well. The user requirements should be properly aligned with business requirements and rank priorities accordingly.
Expectations and constraints by various stakeholders that needs to be fulfilled in order for the project to take off.
Functional and non-functional requirements to be discussed with development and testing personnel.
Size and complexity information concerns by the project manager.

One of the failures in software projects today is the lack of documentation. Make sure all requirements stated in your software project is documented and signed-off. Apart from the project plan, vision & scope, customer & product requirements must be prepared and approved. These documents shall serve as the basis for project planning, testing, and customer acceptance.

Avoid including fancy features that were not defined to be needed in the project. Each unnecessary function added, even on goodwill, has a cost allocated to it. Poor documentation of Vision & Scope or Project Charter can impact all succeeding project documentation.

3. Identify your success criteria.

Each feature or component in your requirements was included for a specific reason. Whatever that is, it must be cited along with its goals met and success criteria. This is the only way you can measure whether you have met your objectives.

A success criteria can be a business statement like “decrease the number of days for order processing from 5 to 3 days” to technical statement like “complete monthly sales report generation in 30 minutes”.

4. Identify users and stakeholders.

Most projects fail due to lack or poorly defined participation of stakeholders. All identified actors in the project must be clear, given appropriate responsibility, time, and resource. They should be made accountable for non-cooperation in the software development project.

One factor overlooked that may result to poor cooperation is the lack of knowledge about the software development lifecycle. That is why it is important to have a workshop during the start of the project to level the knowledge among project participants and other relevant stakeholders.

5. Project priorities.

Customers should know the cost and implications of adding new features or even changing it once implementation starts. This is where your project priorities must be clear and parameters for trade-off defined earlier on. Find out which is fix and flexible: features, cost, and schedule. An example can be, “Given fix cost, we will choose the features and adjust the schedule as necessary.

The importance of knowing your project priorities makes handling of request for changes as realistic and reasonable as possible, with fairness and flexibility to all parties concerned.




Home Training Lessons Learned in Software Process Improvement Forum Articles Philippine Software Industry 2010 Flight Plan Making the Philippines CMMI Self-Sufficient Products Bookstore SPI Forum Photo gallery Janette Toral DigitalFilipino SoftDev Conference 2010 on February 24, 2010 Hotel Intercontinental, Makati City

Improve software development quality		The Requirements Analyst Role by Janette Toral (view photo gallery for a bigger image size) In the requirements management phase of the software development lifecycle, the role is carried out by a person referred to as a requirements analyst or its counterpart. Scope of work requires skill in user interaction, documentation, data gathering, negotiation skills, team leadership, complete-cycle software development experience, among others to be able to perform the following task: 1. Talk to users and project proponents. Data gathering can come in many ways such as use cases, workshop, video conferencing, prototyping, survey, meetings, document review, natural observation, and user interviews. Preparation is important. If there are several options being considered and information is available, a comparative evaluation will also be performed. After every meeting, minutes are prepared for concurrence with the client. Until sufficient information is gathered, drafting of documents, such as the Vision and Scope document (sometimes referred to as Project Charter), that shall serve as a preliminary agreement with the client, can’t proceed. 2. Document the requirements. The requirements analyst should be able to document the requirements in the following areas: Business requirements stated by project sponsor. This shall serve as the ground work for the vision and scope of the project. User requirements given by user representatives. This details the tasks that users must be able to perform with the new application. Quality attributes, like maintainability and usability, are noted here as well. The user requirements should be properly aligned with business requirements and rank priorities accordingly. Expectations and constraints by various stakeholders that needs to be fulfilled in order for the project to take off. Functional and non-functional requirements to be discussed with development and testing personnel. Size and complexity information concerns by the project manager. One of the failures in software projects today is the lack of documentation. Make sure all requirements stated in your software project is documented and signed-off. Apart from the project plan, vision & scope, customer & product requirements must be prepared and approved. These documents shall serve as the basis for project planning, testing, and customer acceptance. Avoid including fancy features that were not defined to be needed in the project. Each unnecessary function added, even on goodwill, has a cost allocated to it. Poor documentation of Vision & Scope or Project Charter can impact all succeeding project documentation. 3. Identify your success criteria. Each feature or component in your requirements was included for a specific reason. Whatever that is, it must be cited along with its goals met and success criteria. This is the only way you can measure whether you have met your objectives. A success criteria can be a business statement like “decrease the number of days for order processing from 5 to 3 days” to technical statement like “complete monthly sales report generation in 30 minutes”. 4. Identify users and stakeholders. Most projects fail due to lack or poorly defined participation of stakeholders. All identified actors in the project must be clear, given appropriate responsibility, time, and resource. They should be made accountable for non-cooperation in the software development project. One factor overlooked that may result to poor cooperation is the lack of knowledge about the software development lifecycle. That is why it is important to have a workshop during the start of the project to level the knowledge among project participants and other relevant stakeholders. 5. Project priorities. Customers should know the cost and implications of adding new features or even changing it once implementation starts. This is where your project priorities must be clear and parameters for trade-off defined earlier on. Find out which is fix and flexible: features, cost, and schedule. An example can be, “Given fix cost, we will choose the features and adjust the schedule as necessary. The importance of knowing your project priorities makes handling of request for changes as realistic and reasonable as possible, with fairness and flexibility to all parties concerned. Copyright 2001-2010 Janette Toral, DigitalFilipino.com Contact details: Janette Toral, 51 Sapphire St.Fern Village Barangay Tandang Sora Quezon City 1116 Philippines, Telephone:+63.9209508696 Do you like this website? Tell your friends about it!