As already outlined, non-functional requirements are a crucial success criterion in distributed systems (and in software development in general). These requirements need to be prioritized in order to focus on the main use-cases of the system. Beside prioritization, using a clear syntax is important as well because non-functional requirements tend to be fuzzy. This limits the acceptance during development. Like their functional siblings, non-functional requirements should adhere to the following criterions as well:
- Clear and non-ambiguous
- Described by using simple and consistent terminology which is well-known by all stakeholders
- Testable at the end of the day in order to achieve a measurable outcome
- Traceable from the beginning until the end (architecture, design, implementation, test, roll-out)
- Technical feasible considering the tools and systems that are part of development and deployment scenario
- Realistic in realization which depends on the planning horizon, the skill-set and location(s) of the team, the infrastructure and the development environment
Ideally, a designated requirement manager and a software architect are the perfect team members to make this happen. All stakeholders should agree on this proceeding in the beginning and are asked to monitor the adherence over the whole lifetime. “Lessons learned” are a good approach to refine this process. Good and bad examples should be used to tune a successful requirement management to perfection.
No comments:
Post a Comment