vragen defining problem and scope
play

Vragen Defining Problem and Scope Noem 3 software proces modellen - PowerPoint PPT Presentation

Vragen Defining Problem and Scope Noem 3 software proces modellen A problem can be expressed as: Wat de overeenkomst tussen de moderne proces A difficulty the users or customers are facing, modellen? Or as an opportunity


  1. Vragen Defining Problem and Scope • Noem 3 software proces modellen • A problem can be expressed as: • • Wat de overeenkomst tussen de moderne proces A difficulty the users or customers are facing, modellen? • Or as an opportunity that will result in some benefit such as improved productivity or sales such as improved productivity or sales. • Wat is het nut van domein analyse? W t i h t t d i l ? • The solution to the problem normally will entail e so ut o to t e p ob e o a y e ta developing software • A good problem statement is short and succinct / Faculteit Wiskunde en Informatica / Faculteit Wiskunde en Informatica 15-2-2010 PAGE 0 15-2-2010 PAGE 1 Defining the Scope Processes in requirements engineering • • Requirements elicitation Narrow the scope by defining a more precise y g problem • Requirements specification • List all the things you might imagine the system doing • Requirements validation and verification − Exclude some of these things if too broad Exclude some of these things if too broad • Requirements negotiation − Determine high-level goals if too narrow • Specification Example: A university registration system p y g y Initial list of problems Narrowed Scope of with very broad scope scope another system Documentation & Elicitation Validation Management g browsing courses browsing courses room allocation room allocation registering registering exam scheduling exam scheduling fee payment fee payment Negotiation Negotiation fee payment f t / Faculteit Wiskunde en Informatica 15-2-2010 PAGE 2 / Faculteit Wiskunde en Informatica 15-2-2010 PAGE 3

  2. What is a Requirement ? Types of Requirements • • Functional requirements It is a statement describing either g • Describe what the system should do • 1) an aspect of what the proposed system must do, • Quality requirements • or 2) a constraint on the system’s development. • • C onstraints on the design to meet specified levels of C onstraints on the design to meet specified levels of • In either case it must contribute in some way towards I ith it t t ib t i t d quality adequately solving the customer’s problem; • Platform requirements • the set of requirements as a whole represents a • C C onstraints on the environment and technology of the t i t th i t d t h l f th negotiated agreement among the stakeholders. system • Process requirements • • A collection of requirements is a requirements A collection of requirements is a requirements • C onstraints on the project plan and development document . methods / Faculteit Wiskunde en Informatica / Faculteit Wiskunde en Informatica 15-2-2010 PAGE 4 15-2-2010 PAGE 5 Functional Requirements Quality Requirements • • All must be verifiable What inputs the system should accept • Examples: Constraints on • What outputs the system should produce • Response time • • Throughput Throughput • What data the system should store that other • Resource usage systems might use • Reliability • Availability • What computations the system should perform • Recovery from failure • All Allowances for maintainability and enhancement f i t i bilit d h t • The timing and synchronization of the above • Allowances for reusability / Faculteit Wiskunde en Informatica 15-2-2010 PAGE 6 / Faculteit Wiskunde en Informatica 15-2-2010 PAGE 7

  3. Elicitation techniques Interviewing • Asking: • Others: • g Conduct a series of interviews • • • interview analysis of natural Ask about specific details language descriptions • • Delphi technique Ask about the stakeholder’s vision for the future • domain analysis domain analysis • • • • brainstorming session brainstorming session Ask if they have alternative ideas Ask if they have alternative ideas • Business Process • Observing • Ask for other sources of information Redesign (BPR) • Ask them to draw diagrams • task analysis • • prototyping prototyping • scenario analysis • ethnography • form analysis form analysis • synthesis from existing system / Faculteit Wiskunde en Informatica / Faculteit Wiskunde en Informatica 15-2-2010 PAGE 8 15-2-2010 PAGE 9 Brainstorming Observation • • Appoint an experienced moderator Read documents and discuss requirements with • Arrange the attendees around a table users • • Decide on a ‘trigger question’ Shadowing important potential users as they do • • Ask each participant to write an answer and pass Ask each participant to write an answer and pass their work their work the paper to its neighbour • ask the user to explain everything he or she is doing • Session video taping p g ! ! ! ! ! ! • Joint Application Development (JAD) is a technique based on intensive brainstorming sessions / Faculteit Wiskunde en Informatica 15-2-2010 PAGE 10 / Faculteit Wiskunde en Informatica 15-2-2010 PAGE 11

  4. Task Analysis Task Analysis • Task analysis is the process of analyzing the way • Task analysis concentrates on the current situation. y y g y y people perform their jobs: the things they do, the However, it can be used as a starting point for a new things they act on and the things they need to know. system: • The relation between tasks and goals: a task is • The relation between tasks and goals: a task is • users will refer to new elements of a system and its • users will refer to new elements of a system and its functionality performed in order to achieve a goal. • scenario-based analysis can be used to exploit new • Task analysis has a broad scope. y p possibilities ibiliti / Faculteit Wiskunde en Informatica / Faculteit Wiskunde en Informatica 15-2-2010 PAGE 12 15-2-2010 PAGE 13

Recommend


More recommend