MOSS Forum

Ask Question   UnAnswered
Home » Forum » MOSS       RSS Feeds

PM/BA tools and resources

  Date: Nov 01    Category: MOSS    Views: 509

Is there and good sites, samples, tools, and/or resources for writing SharePoint
requirements? In example would I document a functional requirement as:: site XYZ
will have a calendar, an announcements section, a news section, there will be a
list with x# of metadata columns, and a view that displays… Etc. are those
typical types of functional requirements you document and what should be
assumptions:: AD is setup and functioning, there will be 2 developer resources
provided by client...? What am I supposed to document in the requirements
without going overboard and without rehashing OOTB functionality? Anything
dealing with writing requirements for SharePoint would be helpful. Thanks in



3 Answers Found

Answer #1    Answered On: Nov 01    

Just an off-the-cuff reaction, but if you have to stop and define a term
(e.g. "metadata column") to a business user, then it probably shouldn't be
in functional requirements.

Functional reqs are about what the end user needs to accomplish. A good
guide for this is the concept of the User Story, as employed in Agile
project management. The basic format is as follows:

As a _______ (what type of user),

I want _________

so that I can ___________

This kind of requirement requires (heh) that you also define acceptance
criteria, i.e. a list of end results by which you can determine that the
requirement has been fulfilled.

Answer #2    Answered On: Nov 01    

Thanks, that gives me a good start to think about "reverse
engineering" my meeting notes so to speak, for example in our HR Dept.
meeting with the client, they said something along the lines of "I want to
see a database of all our employees, with things like there demographics,
but also want the see the benefits they enrolled in, their spouse &
children's names, etc. right now we are keeping it in a spreadsheet on my
desktop, backed up to the network share" and they went on with that. So what
you are saying is I should review my notes and put it in as requirements
document as follows:

As the HR Department Employee
I want to see a centralized list of all employees records on our department
so I can drill down into a specific employee record.

So where do I put the specifics of the field values they want to see? I am a
developer at heart that has moved into a PM/BA role, so as a developer I

Employee list view trimmed down for above but then I see:
When they click an individual employee id num (which is the title column
linked to the item) they see all the other Emp info in the view .aspx screen

Really just OOTB functionality, but the project specifics need configured
with SP, but I still need to document it as above b/c we are pretending the
developer has no clue there of? Again where do I put the specifics of the
fields? Do I do another functional requirement based on same user
perspective as below like:

As the HR Department Employee
I want to see a list of all employees information such as: SS#, Emp Name,
Emp Num, benefits type, spouse name, etc. (I would list all in FR)
so I can view or choose to edit the employees information

Seems, like I need to play tech stupid and pretend the developer has no idea
of what I am talking about. Am I on the right track there? Another question,
do I then number them and add to a trace matrix for results on test cases of
the other side, to trace back if something got missed? I came from a very
dysfunctional place where we did none of this, it was met and bang it out
quickly, so it's a bit of an adjustment for me. Thanks Peter appreciate it!

Trace matrix would have
1.0 - Employee records list
1.1 View all records
1.2 View individual records

Answer #3    Answered On: Nov 01    

The specifics would go into the acceptance criteria. As the agile guys
will tell you, a user story is really "a reminder to have a conversation".
The user story gives a broad idea of one particular piece of desired
functionality; from there, the appropriate team members should flesh out
the acceptance criteria so you know when the story is completed. In your
case, one particular criterion for the employee detail page story might
look like this:

"The employee detail view shows the following fields: first name, last
name, employee ID number, current sick days, and favorite kind of dog."

The employee list would be a different story from the employee detail.
Each piece of functionality gets its own story to minimize confusion.

There's a whole lot more to Agile methodology than this, but hopefully you
can already see its value in organizing the thoughts of various team

Didn't find what you were looking for? Find more on PM/BA tools and resources Or get search suggestion and latest updates.