|
|
|
|
|
|
|
|
 |
|
|
|
- With 'stakeholders' (p. 114-117):
- Questionnaires.
- Interview users.
- Review existing documentation.
- Observe business procedures.
- Research vendor solutions (p. 135).
- Problem: For each of these methods determine what they can and cannot do.
- What do you really want/need to know?
- What are the business processes that the system must support?
- Work flow view: What are the business processes from the actors' point of view? Who does what? Who is responsible for what tasks? How are tasks sequenced and how are they dependent on each other?
- Data flow view: Where, when and to whom does information flow? Under which conditions does it flow? How do new data change the state of things?
- Always keep in mind: system is an abstraction; a model.
- What if the existing business processes are inefficient or ineffective?
- Default: Not a system design responsibility --> adapt the system to the business processes.
- Option: adapt the business processes: business process reengineering (BPR (p. 136)).
- Enterprise Resource Planning (ERP) systems.
- Not the authority of the system designers.
- How do we acquire this information?
- Traditional: ask the stakeholders what the system should do.
- Problem: why does this almost never work?
- Modern: task-centered design: business process scenarios: use-cases:
- Lewis and Rieman downloadable book on task-centered (user interface) design.
- Stakeholders describing their jobs/tasks in detail:
- Task timing:
- Absolute; e.g., at 8:00 AM on weekdays, a report is generated...
- Relative; e.g., X generates the data, then sends them to Y.
- Required data:
- Source (organisation, location).
- Formats.
- Ownership/responsibilities.
- Consequences of not meeting the task timing requirements.
- Develop multiple scenarios or use-cases: normal workdays, special days (holidays, weekends), exceptional/crisis situations, etc.
- Problem: Why does this almost always work?
- Our job as system designers:
- Carefully document the business processes: customer review and modification until customer signs off!
- Translate (abstract!!!) the process in system's characteristics (where, when and to whom do data flow?): Workflow diagrams (p. 127):
- Task/Data sheets (customer can easily review).
- Diagrams (p. 129): customer does not (normally) review.
- Have you got everything? (p. 137)
- Scenarios/use-cases will function as cognitive walkthrough documents throughout the remainder of the design.
- Internal inconsistenties.
- Missing elements.
- Duplicate representation.
- Internal reviews.
- Documentation.
- !!!Note that the results from the requirements/needs analysis do not(!!) contain technical specifications!!! Strictly speaking, requirements/needs analysis stops here.
- How to do this for our case study? Example: Colorado River 24-Month Study.
