Every project though must have some level of requirements vetting in order to satisfy expectations for potential return on investment or affordability. These types of efforts are generally manual although some folks use models to help with cost estimation. At some point though, the high level or functional Requirements and Work Breakdown Structure (WBS) must be defined in order to set up project schedules.
With PLM, we can tackle this by developing a Semantic blueprint or foundation. The way I've approached this before is to use preliminary visualization tool (mind map or concept) to illustrate the functional requirements and the relationships between them. I then designate that as a Domain Taxonomy (or ontology depending on how detailed the relationship information is). The Domain Taxonomy then represents the pool of available terms groups and sub-groups with which to build logically relevant WBS segments. Then I build requirements taxonomy within my automation environment and extract the WBS from it. Thus I have elements of EA design, semantic correlation and project coordination all wrapped up within one activity. This makes it possible to track from:
- Strategy to EA
- EA to Functional Requirements (the 1st level or elementary taxonomy)
- Functional Requirements to WBS (abstraction of 1st level taxonomy)
- WBS to Technical Requirements (the 2nd level or detailed taxonomy)
- Technical Requirements (precise) to Project Schedules (schedule & detailed requirements taxonomy should map nearly one to one)
- Project Schedules to Roadmaps & What if Alternatives
- and everything back to Strategy
Understanding functional requirements implies domain knowledge, both in terms of domain entities and relationships.
Copyright 2008, Semantech Inc.
Posts
No comments:
Post a Comment