| Inconsistent Characterization of Requirements in Elaboration [message #567557] |
Mon, 06 November 2006 23:16 |
 Jim Ruehlin
Messages: 73
Registered: July 2009 |
Member |
|
|
Hello,
I've been reviewing OpenUP/Basic, and I noticed that we don't have much
to say about detailing requirements in the Elaboration phase. What we do
have is somewhat contradictory (see Concept: Elaboration Phase and the
Manage Requirements section under Activity: Elaboration).
I'd like to see us provide more guidance on this and handle it
consistently. I'd be inclined to say that only high-risk and
architecturally significant requirements are detailed during
Elaboration. The reason is to stay focused on what's important for that
phase. Also, producing requirements documents without implementing the
corresponding system features doesn't provide value to the stakeholders.
There's another reasonable school of thought that says about 80% of
requirements should be detailed during Elaboration so better project
planning can be performed and the system will be understood better. An
Agile argument against that is that we don't REALLY know if we
understand the system until it's built, so the requirements should be
detailed just-in-time.
What do others think?
Jim Ruehlin
jruehlin@us.ibm.com
|
|
|
Powered by
FUDForum. Page generated in 0.02791 seconds
] 
Search
Help
Register
Login
Home
