Home
About Us
Advertise
Printable version
Writing the right requirements — Part II
By Eric Riz
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.
Next Page
Pages
1
2
3
Share this link:
https://sptechweb.com/link/36209
Related Articles
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
The SharePoint Web Part Gallery
Browsing your Web Parts is easier than it looks; here are some tips for navigating through the Gallery
Write the right requirements
In order to define the right requirements, one must first obtain the proper frame of reference from team members
Add comment
Name*
Email*
Country
United States
Canada
Afghanistan
Albania
Algeria
American Samoa
Andorra
Angola
Anguilla
Antarctica
Antigua & Barbuda
Antilles, Netherlands
Arabia, Saudi
Argentina
Armenia
Aruba
Australia
Austria
Azerbaijan
Bahamas, The
Bahrain
Bangladesh
Barbados
Belarus
Belgium
Belize
Benin
Bermuda
Bhutan
Bolivia
Bosnia and Herzegovina
Botswana
Brazil
British Virgin Islands
Brunei Darussalam
Bulgaria
Burkina Faso
Burundi
Cambodia
Cameroon
Cape Verde
Cayman Islands
Central African Republic
Chad
Chile
China
Christmas Island
Cocos (Keeling) Islands
Colombia
Comoros
Congo
Cook Islands
Costa Rica
Cote D'Ivoire
Croatia
Cuba
Cyprus
Czech Republic
Denmark
Djibouti
Dominica
Dominican Republic
East Timor (Timor-Leste)
Egypt
El Salvador
Equatorial Guinea
Eritrea
Estonia
Ethiopia
Falkland Islands (Malvinas)
Faroe Islands
Fiji
Finland
France
French Guiana
French Polynesia
Gabon
Gambia, the
Georgia
Germany
Ghana
Gibraltar
Greece
Greenland
Grenada
Guadeloupe
Guam
Guatemala
Guinea
Guinea-Bissau
Guinea, Equatorial
Guyana
Haiti
Holland (see Netherlands)
Honduras
Hong Kong, (China)
Hungary
Iceland
India
Indonesia
Iran, Islamic Republic of
Iraq
Ireland
Israel
Italy
Jamaica
Japan
Jordan
Kazakhstan
Kenya
Kiribati
Korea (North)
Korea (South)
Kuwait
Kyrgyzstan
Laos
Latvia
Lebanon
Lesotho
Liberia
Libyan Arab Jamahiriya
Liechtenstein
Lithuania
Luxembourg
Macao, (China)
Macedonia, TFYR
Madagascar
Malawi
Malaysia
Maldives
Mali
Malta
Marshall Islands
Martinique
Mauritania
Mauritius
Mayotte
Mexico
Micronesia, Federated States of
Moldova, Republic of
Monaco
Mongolia
Montenegro
Montserrat
Morocco
Mozambique
Myanmar (ex-Burma)
Namibia
Nauru
Nepal
Netherlands
Netherlands Antilles
New Caledonia
New Zealand
Nicaragua
Niger
Nigeria
Niue
Norfolk Island
Northern Mariana Islands
Norway
Oman
Pakistan
Palau
Palestinian Territory
Panama
Papua New Guinea
Paraguay
Peru
Philippines
Poland
Portugal
Puerto Rico
Qatar
Reunion
Romania
Russia (Russian Federation)
Rwanda
Saint Helena
Saint Kitts and Nevis
Saint Lucia
Saint Pierre and Miquelon
Saint Vincent and the Grenadines
Samoa
San Marino
Sao Tome and Principe
Saudi Arabia
Senegal
Serbia & Montenegro
Seychelles
Sierra Leone
Singapore
Slovakia
Slovenia
Solomon Islands
Somalia
South Africa
Spain
Sri Lanka (ex-Ceilan)
Sudan
Suriname
Swaziland
Sweden
Switzerland
Syrian Arab Republic
Taiwan
Tajikistan
Tanzania, United Republic of
Thailand
Timor-Leste (East Timor)
Togo
Tokelau
Tonga
Trinidad & Tobago
Tunisia
Turkey
Turkmenistan
Turks and Caicos Islands
Tuvalu
Uganda
Ukraine
United Arab Emirates
United Kingdom
Uruguay
Uzbekistan
Vanuatu
Vatican City State (Holy See)
Venezuela
VietNam
Virgin Islands, British
Virgin Islands, U.S.
Wallis and Futuna
Western Sahara
Yemen
Zambia
Zanzibar
Zimbabwe
[Not specified]
Comment
Preview