Inception

Inception

1. A structured description of system usage and function

   • Nowadays requirements documents are not favoured

2. Requirement Capture/ "User Centred Design"(UCD)

   • Psychological Approach
     • Design a conceptual model.
     • Anticipate what will happen when user tries to use system
     • promote understanding by reducing:
       • gulf of execution, user knows what they want to do, but not how.
       • gulf of evaluation, user is given incomprehensible feedback, doesn't understand what mistake they have made and thus can't learn.
   • Anthropological Approach
     • Carry out fieldwork
       • interview USERS
         • emphasis on user tasks, not technical issues
       • understanding context in which they work
         • look at division of labour, measures of success and failure, exceptions to rules, interface between paperwork and computerwork, spatial and temporal organisation.
       • Discover things by observation that may not be in requirements
     • Collaboration with users to identify problems to solve and how they might be solved
     • Ethnographic field studies
       • understand real detail of their activity
       • Observe context of people's lives, participate in activities
     • User Personas
       • Make a "character" who has a background and needs.
       • Help designers to remember that their clients are PEOPLE.
   • Gould and Lewis 1985
   • Principles
     • Focus on users, need to understand them, do so by studying them
     • Test user responses to prototypes
       • Can then iterate and fix problems
     • Good communication of requirements, shouldn't need documentation!
   • Defining System-Use Scenarios
     • From requirements, describe human activity that system must support
     • Can suggest interactions between software objects.
   • Functional vs Non-Functional requirements
     • Functional describe what the system does
     • Non-Functional describe how they system does it
       • constrains functional requirements
       • Categories
         • Performance (how fast) Technological (on what) Accessibility (meets external guidelines) Security (for payments etc, external guidelines) Capacity (how many/much can it take) Reliability (uptime)

3. Use case diagrams

   • Show the system within a box, collect all behaviour together
   • Use stick-figures as "actors" which play a system role even when they are not human, to be simple for clients to understand
   • "Associate" actors (using solid lines) with use cases, shown as bubbles containing a description of the use case.
     • There may be relationships between use cases (inclusion, extension, generalisation) shown with dotted lines.
     • Use cases should show EVERY interaction, even logging in or registering

4. Deriving objects from a Scenario

   • Using a description of the software, the nouns will refer to classes whereas the verbs correspond to methods.
     • Having extracted them can then merge nouns and verbs to generalise, and assign verbs to nouns.
   • From this can make (Class Responsibilities, Collaborators) CRC cards
     • Allows you to reorganise system and move objects around, visual representation.
     • Provides interface between desinger and analyst/client

5. Requirement Prioritisation

   • Use of MoSCoW system