Writing the right requirements — Part II

By Eric Riz

December 21, 2011 — (Page 1 of 2)
This is the second of three in a series on writing the right requirements (read Part I and Part III, too), written exclusively for SPTechWeb and the SPTechRerport newsletter, and ahead of my requirements workshop at SPTechCon in February. I hope that the first article assisted project managers out there with suggestions on how to engage the business unit, define a user community and create a phased approach to your SharePoint project. Thanks to those who reached out and provided feedback on their thoughts and successes; I look forward to receiving more notes from readers.

This article is focused on the process behind eliciting and prioritizing requirements, and the third will suggest how to document and action your requirements into meaningful, tangible, actionable statements that your developers can begin working on immediately.

When working with your team on eliciting and prioritizing requirements, your first task is creating a measurable baseline and common understanding of the goals and expectations for your requirements. Without this common framework and measurement, you and your team are destined for failure.

Think of this as the equivalent to preparing for a trip. Before leaving home, you would have your initial requirements in hand: the duration of your trip, the weather at your destination, your planned activities while away, and what clothes you'll need to pack. These are your variable requirements, those which you have no control over and have external dependencies (you can pack all you’d like, but the airline can still lose your luggage).

Next, you would confirm that your fixed requirements are in place; these are things that you would have a difficult time replacing while away, such as cash, medication, glasses or contact lenses. The point is, what takes priority on your list and what makes one item more important than another? This is the question your team needs to ask to be efficient and effective when writing requirements.

Pages 1 2

Share this link: https://sptechweb.com/link/36209

Writing the right requirements — Part III Getting your requirements in understandable and actionable statements is a critical step toward implementation

Writing the right requirements — Part I In order to define the right requirements, one must first obtain the proper frame of reference from team members

A lesser-known Web Part connection option Selecting data from one Web Part can automatically perform an action on the data in a connected Web Part

Add comment

Name*
Email*
Country

Compose

Writing the right requirements — Part II

By Eric Riz

Related Articles

Add comment