index.md (3570B)
1 +++ 2 title = 'Requirements' 3 +++ 4 # Requirements 5 ## Types of requirements 6 - Functional requirements 7 - what the system must do, how to react to runtime events 8 - satisfied by assigning appropriate seq of responsibilities throughout design 9 - Quality attribute requirements 10 - qualifications of functional requirements, e.g. how fast something must be done 11 - satisfied by structures designed into architecture, and behaviors/interactions of elements in those structures 12 - Constraints 13 - design decisions where you have no freedom, e.g. using a certain programming language or reusing certain module 14 - satisfied by dealing with it (in fancy language, "reconciling the design decision with other affected design decisions") 15 16 Neither functions nor quality attributes stand on their own 17 18 Two categories of quality attributes: 19 - development time qualities 20 - runtime qualities 21 22 ## Architecturally significant requirements 23 Architectures mostly driven by quality attribute requirements, features/functionality not as much 24 Something like "the system must be modular" isn't enough; what's the reason? Has to be quantified and specific. 25 26 Finding ASRs: 27 - requirements documents (but often little info, architecture can't wait for requirements to be finished) 28 - interviewing stakeholders (tells you what they want, but often they have no idea, and you might get random numbers from them) 29 - understanding business goals (often lead to quality attribute requirements, may directly affect architecture) 30 31 ## Business goals 32 Business goals often lead to QA requirements, may directly affect architecture. 33 Some may be satisfied without using the architecture (e.g. to reduce cost, stop heating the offices when everyone's working from home) 34 35 There are some standard categories, e.g. meeting financial/personal objectives, meeting responsibility to employees/society/state/shareholders, managing market position, managing change in environmental factors 36 37 Expressing business goals: 38 39 > "For {system being developed}, {goal subject} desires that {goal object} achieve {goal} (in the context of {environment}) and will be satisfied if {goal measure}." 40 41 ## Requirements and goals 42 Goals are the "why", requirements are the "how". 43 44  45 46 ## Quality attribute scenarios 47 Specifies quality-attribute-specific requirement. 48 49 Six parts: 50 1. stimulus: event arriving at system (input) 51 2. Source of stimulus 52 3. Response of system (output) 53 4. Response measure - how you determine that response is satisfactory 54 5. Environment - conditions when stimulus happens 55 6. Artefact - which portions of system does requirement apply to 56 57  58 59 ## Capturing ASRs in utility tree 60 Utility as root (expression of overall 'goodness' of system). 61 Elaborated into QAs, decomposed into attribute refinements, expressed in ASRs (usually as QA scenarios) 62 63 For example: 64 65  66 67 Assess the ASRs in terms of business impact and architectural impact (high, medium, low): 68 69  70 71 Checks based on utility tree: 72 - have all QAs been refined and expressed in ASRs? 73 - where are the risks? (H,H) ratings 74 - are all concerns addressed? 75 76 ## Usability 77 How easy it is for user to accomplish tasks, what support system provides for user. 78 79 Dimensions: 80 - learning features 81 - using it efficiently 82 - minimizing impact of errors 83 - adapting to user's needs 84 - increasing confidence and satisfaction