SPTechWeb Logo
Home About Us  Advertise       
 
 

Writing the right requirements — Part II




December 21, 2011 —  (Page 1 of 3)
This is the second of three in a series on writing the right requirements, 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.

My recommendation for requirements creation is to start with the most common component within SharePoint, the portal. The SharePoint portal is the foundation of almost every deployment, as it provides and fosters a starting point or login page for all departments. From my experience, it is the most understood concept within the SharePoint world, as most users appreciate what an intranet is, and it’s more than likely that your portal will replace some type of internal system.


Pages 1 2 3 


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

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading



 
 
This site's content Copyright © 1999 - 2012 by BZ Media LLC, All rights reserved.
Legal and Privacy
• E-mail: