7 steps to define good project requirements?

  1. Identify the project’s stakeholders
  2. Classify them into groups of;
    1. High power – high interest
    2. High power – low interest
    3. Low power – low interest
    4. Low power – high interest
  3. Collect the detailed requirements from the relevant stakeholders through;
    1. Interviews
    2. Questionnaires
    3. Brainstorming
    4. Requirements development workshops
    5. Benchmark with similar projects / products
  4. Analyze the requirements
  5. Define requirements
  6. Collect feedback (prototyping)
  7. Freeze / baseline requirements

Every project starts with a high level scope description. Sometimes it can be just a problem definition. This has to be elaborated into detailed scope. The first and foremost step is the identification of the stakeholders of the project. Stakeholders are anyone who are affected positively or negatively, directly or indirectly by doing the project, or by not doing the project, or by delaying the project. Unless and until we identify the key stakeholders, requirements definition can err.

The following diagram depicts the stakeholders for an online project management course;

Online Project Management Course Stakeholders

A good understanding of the key stakeholders is the first step towards collecting good project requirements. Once the stakeholders are identified, we are ready to collect / develop detailed requirements from the key stakeholder’s perspective. From the above stakeholder diagram, it becomes easier to visualize the high level major modules like;

  • Administrator module
  • Participants module
    • First time visitors
    • Repeat visitors
    • Progress / scores
  • Instructors module
  • Content developers module
  • Payments module

Can we estimate these modules?. The answer is ‘No’ because they are at a very high level. They need to be elaborated further. The jargon used for requirements engineering for traditional project management and for agile project management differ and at the same time the ‘common goal’ is to identify and define accurate and relevant requirements hence an awareness of these jargon will be helpful.

Requirements collection

In traditional project management we collect detailed requirements through interviews, questionnaires, brainstorming with the stakeholders. The requirements thus collected are analysed, elaborated and documented as the requirements specification document.

In the agile world, everything starts with the product backlog. The product backlog contains the wish list of features that may or may not get into the product. The very high level features which needs to be broken down further are known as epics. In our example of developing an online project management course, the following are at an ‘epic’ level, which need to be decomposed further into features (The list of probable features are provided within brackets).

  • Administrator module (Super admin, admin, authorizations, revokes )
  • Participants module
    • First time visitors (registration, enrollment, language)
    • Repeat visitors (course)
    • Progress / scores (sponsor, student)
  • Instructors module (course development, evaluations, time tables, assignments, tests)
  • Content developers module (development, submission, quality control, multi language)
  • Payments module (payments, refunds, credit cards, debit cards, bank transfer, multi currency)

What we have now are the epics and the probable features related to the epics. These features are further broken down into ‘user stories’.

Contents of ‘user stories’ 

  • Header – New User registration
  • Description :
    • As a new user I can create my unique user-id and password
    • As a new user, I should be able to choose the course of my interest
    • As a new user, I should be able to see the profile of the instructor
    • As a new user, I should be able to see the details of other participants
    • As a new user, I should be able to see the details of the course
    • As a new user, I should be able fill up my profile
  • Conversations – are captured as and when someone has a query
  • Acceptance tests
    • User id must be unique, between 7 to 15 in length. Can contain alphanumeric.
    • Must contain one digit, one capital letter

A user story must be something that can be developed and demonstrated within 2-4 days time. If that criteria is not met, then that story must be broken down further into sub-stories. The sequence goes like this;

  • High level scope
    • Epics
      • Features
        • User-story
          • Sub-story

Irrespective of the framework or the development cycle followed, our objective must be to collect accurate and relevant requirements without any ambiguity, in the shortest possible time. Product backlog / epic/ feature / story route is my preferred path, because it is easy to manage. Sometimes we get the requirements specification as an input to the development process, in that case decompose the requirements documentation into stories (when we write the acceptance tests, the clarity of the the requirements increases). If the customer wants the requirements specification document as a deliverable, then take the agile route for requirements engineering, and then combine all your stories to form the requirements specification document. Remember ‘The cost of managing requirements related defects during the requirements phase is one hundred times lower than correcting them once the product is developed’.

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: