Requiements capture

Gathering requirements is both an art and a science. There are numerous project templates on the web that can be used to capture or gather project requirements.

It is a science because these templates guide an analyst to gather the user requirements for a project. It is an art because the template only has headings or guidelines. It is a generic template and the analyst has to use common sense and industry knowledge to probe and distill user requirements into a specific, measurable and deliverable requirement.

Most requirements focus on the functional aspect of a project. These are termed "user requirements". These are the functions or use cases the user must have or would like to have delivered through the project.

The architectural requirements are normally done as part of design, or worse still, an after-thought. I define architectural requirements as other requirements not pertaining to the functional aspect of the project. For example, security requirements, performance requirements, scalability and extensibility requirements, availability requirements. From this list alone, you can deduce that the term "user" goes far beyond the business user or the user that specifies the functional use cases. The project team's interaction must now encompass the customer's security team, systems and infrastructure team, application maintenance team.

If requirements capture is viewed in this manner, the project team will begin to identify the various "users" needed for project success and begin building close working relationships with the extended eco-system. The relationships cannot be a one-off relationship. It is an on-going relationship as the project progresses.

Bernard
---------------------------
Save This Page
Copyright © Bernard Ong, 2006-2011.
All Rights Reserved
http://RescueSoftwareProjects.blogspot.com
http://www.bernard-ong.com
http://mrbolt.blogspot.com
http://BuddhismToday.blogspot.com

Reviews are critical in project management!

Core technical skills, software design, writing code are all considered important and critical activities of a project. The perceived "softer" activities such as regular project reviews are considered optional.

This situation is very common in projects. Software design and writing code produces visible results such as the software module or use case that can be viewed and tested. You can't see or view the result of project review. If project reviews are done correctly and properly, and the project progresses without major issues, no one will acknowledge or miss the importance of project reviews. The importance of project reviews are often overlooked.

In my experience, project reviews, if done correctly and properly, keeps the team focused, productive and more importantly, effective. In my opinion, it is a critical activity.

However, how many would agree to this? If the project is on track and progressing well, no one will acknowledge this point. If the project is failing, some may acknowledge this point, others will blame the software design, code quality, coding standards, scope creep. While there is some truth in this, project reviews help prevent major catastrophes and at least, identify and highlight such catastrophe may be on the horizon and the team needs to take corrective action.

Bernard

---------------------------
Save This Page
Copyright © Bernard Ong, 2006-2011.
All Rights Reserved
http://RescueSoftwareProjects.blogspot.com
http://www.bernard-ong.com
http://mrbolt.blogspot.com
http://BuddhismToday.blogspot.com