Requirements & Architecture Traps & Pitfalls - outputs

1. Requirements & ArchitectureTraps & Pitfalls - outputs Rob Machin, Chief Technical Architect @ Concise Chris Cooper-Bland, Solution Architect (Independent) SPA 2006

2. Pitfalls the group came up with

3. Bloody Consultants/Customers Scope Creep Job Protectionism (only analysts understand how to write Use-Cases) Architecture fails to respond to change Inability to descope Tacit (too obvious) requirements never articulated No time to study problem (always in a rush – rush to build) Hard to assess architectural quality – what do we measure? Architecture just emerges – no pre-planning or driven by tools Over-the-wall mentality between teams, silos, teams not co-located Poor or antiquated knowledge Architecture role too fuzzy Extracting requirements from customer too hard (so just extrapolated from patchy domain knowledge within IT) Keeping requirements in synch with models too hard Lack of acceptance criteria/tests/involvement of QA Technology hype Gold plating – needless complexity Fail to recognise can’t define requirements up-front Architecture too high-level for use Common Traps & Pitfalls

4. Anti-Patterns designed by group

5. Anti-Pattern:Hard to assess architecture quality/when fit-for-purpose • Synopsis: • Never sure if we know when an architecture document is complete and sufficiently useful • Symptoms: • Architecture quickly becomes shelf-ware and is not used • Create wrong trade-offs/conflicting trade-offs in the system • Fundamental decisions are deferred • System is too expensive to maintain • Unpleasant surprises during implementation (which architecture should have uncovered) • Solutions: • Iterative development • Architecture reviews – independent testing against scenarios + follow up actions • Architect embedded in teams • Prove highest-risk concepts through prototyping

6. Anti-Pattern:Failing to make things obsolete • Synopsis: • Functionality that is no longer required incurs maintenance effort and adds to the complexity of the system • Symptoms: • Requirements taken from previous system • System grows • Increase in maintenance costs • Organisation developing the system does not know how the system is used in practice • Lethargy/indecision/fear on the part of the business analysts/experts • Use of legacy tools • Migration path not defined • Solutions: • Actively monitor usage of functionality • Planned obsolescence • Understand customer usage • Refactor/re-engineering to make easier to make things obsolete

7. Anti-Pattern:Unplanned architecture • Synopsis: • Developers start by building the system and architecture emerges along the way, but is not good enough (flexibility, performance, scaleable, security) • Symptoms: • Example hacked into a prototype then turned into a production system • Developers have no clear consistent view of the architecture • Architecture breaks when trying to scale, add requirements, etc • Solutions: • Learn from ad-hoc architecture – decide what to keep and what to improve • Document and communicate the architecture within team, to stakeholders, etc • Create review checklists based on architecture for design and code reviews • Traceability of high-level requirements • Bring external expertise to assess architectural quality • Each extension of a system should involve review of basic assumption

8. Anti-Pattern:Paper tiger • Synopsis: • Architecture on paper seems okay, but… • Symptoms: • but in practice it is not working, no test results specified, lots of text references to architecture but no “reference architecture” • Solutions: • Prioritise the architectural risks • Prove them!

9. Anti-Pattern:Models Mismatch • Synopsis: • The solution does not match requirements model • Symptoms: • Does not match • Testers spot anomalies • Integration issues/interfaces • Solutions: • Planning i.e. building in checks to process • Tools • Configuration management • Team structure/communication

10. Anti-Pattern:Inability to describe requirements between user and development teams • Synopsis: • Solution does not match the problem • Symptoms: • Mismatch in understanding between business and team • Poorly defined requirements • Ambiguous statements • Rate of change of requirements documents is high • Tacit knowledge not specified to the development team (too much is assumed knowledge) • Solutions: • Workgroup of understanding the domain/problem • Choosing the right tool/practices to help the customer specify the solution (eg. Use-Cases, prototyping, etc)

11. Anti-Pattern:“One-Shot” Architectures • Synopsis: • Architecture is produced in a non-iterative fashion and subsequently isn’t able to respond to change • Symptoms: • Architecture out of synch with implementation • Architecture enforces a non-optimal solution • Nobody reads the architectural documentation – no respect for the architecture • Architecture is unable to respond to change • Developers and Business are unable to describe the architecture • Solutions: • Architect involved for the lifecycle of the project • Iterative working – the solution feeds back into the architecture • Make the architect “responsible” for the architecture • The architecture must be updated in line with changes to the architecture

12. Anti-Pattern:Failing to make legacy requirements explicit • Synopsis: • Requirements derived from a previous system omit essential characteristics – e.g. time taken to compete a business process • Symptoms: • System goes live but fails to meet business needs • Emergency fixes to workaround the most serious impact of this • Solutions: • Collaborative working: test prototype with business to extract requirements • Risk-based prioritisation: recognise the impact of poor performance etc

13. Anti-Pattern:Inherently hard requirements • Synopsis: • Inherently hard requirements can’t be known by the team until the team has learnt more about the system and the domain context • Symptoms: • System gets increasingly complex, over complex, over configurable in response to growing understanding • Finger pointing between developers and customers • Hard to get traction in early stages • Slow for change control to converge • Very different views from different customers – hard to prioritise • Solutions: • Iterative working – early prototyping (plan to throw one away) • External domain expertise needed to bring team and customers together • Keep close to customers: get customers in the same room as team • Take ownership of joint problem • Try to see bigger business problem