Completed Systems Requirement Review (SRR) on a big program last week and here are some lessons learned:
1. Know the approvers. You'd think this would be easy, but there are circumstances that complicate this. For example, when deploying a COTS product that will be deployed as a general service, who approves? Don't forget security folks!
2. Get to the approvers a minimum of two weeks ahead of time and review.
3. Leadership will provide an endless list of people that 'need to be involved'. Our SRR had over 30 people! Clearly only about 10% would really add value. Figure out who these people are and focus on them.
4. An SRR is about communicating status, not a review of requirements. Give enough detail so that the audience knows you've been in the details
5. Review the slides with the team at least a week before.
The temptation is to see the SRR as a formality, a box to check, since all the hard work has been done. While that's true to a large extent, it really represents the time from when the requirements are completed to the review - that time period is when you're formally closing with the primary stakeholders, and that's important.
Showing posts with label information-systems. Show all posts
Showing posts with label information-systems. Show all posts
Monday, June 23, 2008
Friday, June 13, 2008
What are system requirements?
In the defense industry the word requirements means a series of statements that have the word 'shall' in them. These statements are testable, measureable, and specific. This approach has carried over into the IT industry so that those deploying systems have similiar documents with all the 'shall' statements that the system must do.
For the delivery of information systems, this approach sucks. No one, and I mean NO ONE, can take a document with 300 shall statements and understand what the system will do. Did I say no one?
But here's the rub: when it comes to design, development, testing and deployment, shall statements are very helpful. Shall statements are the machine code that makes the information system development process work, so we can't ignore them.
Too many times I see battles between those that work with users to identify requirements with group facilitation techniques, wireframing, etc. and say the systems engineer's won't connect with users due to their stupid requirements documents (and their right). And the systems engineer's say that the facilitators don't provide enough details to adequately develop systems (and their right).
This is the roll of the chief engineer and program manager - make sure both are happening and that what we discover from the user with user centered techniques translates into the machine code that the developers need.
For the delivery of information systems, this approach sucks. No one, and I mean NO ONE, can take a document with 300 shall statements and understand what the system will do. Did I say no one?
But here's the rub: when it comes to design, development, testing and deployment, shall statements are very helpful. Shall statements are the machine code that makes the information system development process work, so we can't ignore them.
Too many times I see battles between those that work with users to identify requirements with group facilitation techniques, wireframing, etc. and say the systems engineer's won't connect with users due to their stupid requirements documents (and their right). And the systems engineer's say that the facilitators don't provide enough details to adequately develop systems (and their right).
This is the roll of the chief engineer and program manager - make sure both are happening and that what we discover from the user with user centered techniques translates into the machine code that the developers need.
Subscribe to:
Posts (Atom)