|
At the company that I currently work at, Word documents are passed around which contain the features/requirements for the software we write, and those Word docs contain mock-ups (there aren't any use cases that I've seen). I'm just curious what project managers use at other companies. Do some skip making the requirements documents altogether and go straight for a ticket-tracker such as JIRA? What seems to work the best? Thanks, -Jon |
|||
|
|
|
I've worked for a couple of contractors for various (US) government projects. The short answer could be summed up by * (Dramatic pause for laughter) Honestly I've seen everything from a (single) piece of paper scribbled on from a client (passed to me by the PM) to Excel/Word, to a System Spec in combination with a DODAF. Lately I've been working a lot of small projects so I tend to capture these in a Enterprise Architect (UML tool) and then when I need a document I just generate it. At least with the PM's I work with right now they don't define the software requirements, at most they (and/or the client) define the business requirements. I (or the appropriate person) defines the software requirements that fulfill the business requirements. They (client and/or PM) have to sign-off on the SW Requirements but that usually isn't a problem since the SW Requirements contain all kinds of things that the business requirements didn't. Occasionally I have pushed back on a business requirement since it 'disagreed' with another requirement. Usually that just meant the client/PM wasn't really sure what they wanted. |
|||
|
|
|
I've seen everything from a one-word description ("Auction", I guess you needed to know the context) to a hundred-page specifications document. Assuming I have a user available, I like to work with user stories. These are short descriptions of the expected behaviour of the product once the feature is added, long enough to act as an aide memoire and conversation point but short enough to avoid analysis paralysis. |
|||
|
|
|
It depends. When we are working on a large set of related requirements and are going back and forth with the customer we have a document that is "customer friendly". When these are locked down (or as good as they are going to get) we put them in a tracker. If the requirement is a technical requirement and something that wouldn't be appropriate to talk about with the customer or if it is a minor change then it will be "fast-tracked" and go straight to the tracker. |
|||
|
|
|
I do the same as confusedGeek and put everything directly in the usecase diagram. I found that the usecase could really be full of interesting information if saved at model level. I then print a documentation and give it to the developer team. |
|||
|
|
|
We've taken a two pronged approach where the BA will create a functional overview that is meant for the business and our people as a primer. After that are the functional details which are broken into definitions, business justification (as a developer you have to drink a bit of the kool-aid once in a while to get behind a project) and use cases. I created these docs, but our Director still insists on the use cases being in outline form and not simple note cards. I then churn those into technical use cases for us to work from while still using the functional details for business rules in the use cases. In short...don't do what we do. Create a Word doc that has the business position for the solution as well as the definitions and terminology needed in the project. Make the use cases simple, even if they add up to 100+. Once we have the use cases they are listed on a white board and assigned out...no formal system is used at that point but we have meetings (I wouldn't go so far as to say scrums) every other day. |
|||
|
|
