How to Rescue Failing Software Projects: Practical Proven Methods That Work

IMG_1712 My book is finally available as an eBook, on Amazon Kindle and on Amazon. I wrote this book to share my experience in how to rescue failing software projects. When I was going through such a situation, I had no one to turn to. My hope is that the information in this book will be useful to those in similar situations. Although the information in the book pertains to software projects, I have come to realize that the techniques can be used in many other situations. I have personally used these techniques in business and technical projects.

You can read more about it here.
My book can be purchased here at Amazon.com.
Amazon Kindle version is available here at Amazon.com


Saturday, April 09, 2011

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

2 comments:

Anonymous said...

Fascinating post. You have an out of the ordinary evaluation on this matter plus I shall be subscribing to your rss feed along with expect you will post yet again in a little while on parallel subjects. But I am inquisitive on what your expose sources for the publish are? Thank you

Before I go, let me thank you for your understanding with my English as (I'm sure you have figured this at this time ,), English is not my chief tongue accordingly I am using Google Translate to form out what to jot down what I sincerely intend to write .

Bernard Ong said...

Hi.
Thank you for visiting and posting your comments.

I have read several books concerning concerning Use Cases and how it helps.

In my experience, user requirements mainly focus on the functional aspects of a project. Most projects that I encounter have the security, performance aspects considered as an after-thought and always run into issues at the final stages of the project.

I don't have any specific sources but is based on my experience, although I have read on the topic of user requirements from several books.

Hope this helps.
Bernard