Requirements

Published on March 2017 | Categories: Documents | Downloads: 12 | Comments: 0 | Views: 168
of 22
Download PDF   Embed   Report

Comments

Content

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

Wolfram Webers [email protected]

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

What is Analysis? !  Requirements Specificatio Specifications ns ! 



OOA (part 1)

Wolfram Webers

October, 2008

2

!

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

!  ! 

We need to understand the problems first In information system development:   What is the system?

!

!

  Who uses the system?   What is the purpose of the system?   Where is the border of the system?

!

!



From the business perspective:   How do we establish the business requirements for a new system?   What effects will the new system have on the organization?   How do we ensure that the system we build meet its requirements?

!

!

!

Wolfram Webers

October, 2008

4

$

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

A system exists in an environment !  A system can have subsystems !  A system has inputs inputs and  and outputs outputs,, communicating communicati ng with the environment !  A system transforms input input to  to output output   !  Systems that endure have a control control   mechanism !  System control relies on feedback feedback,, and feed-forward   sometimes on feed-forward ! 

Wolfram Webers

October, 2008

5

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

System boundary

Inputs nputs

What  the system does

uts Outp utpu

      l      o      r       t      n      o       C

Feed-Forward

How the system is controlled

Feedback

System environment Source: Bennett, McRobb, Farmer (2006)

Wolfram Webers

October, 2008

6

'

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



Black box   We can see only the interfaces interfaces to  to the system   We can see, what the system needs for inputs inputs     We can see, what the system has as outputs   All All internals  internals are hidden  hidden 

!

!

!

!



Grey box   Additionally to a black box view, we can see the relations between inputs inputs and  and outputs   We still have no insights about the realization

!

!



White box   We can see everything of the system   It’s the developer’s view

!

!

Wolfram Webers

October, 2008

7

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 





Information system in an organization can have different roles Operational systemswork (what the system does)   automate day-to-day !

  mostly transaction transaction based  based

!



Management support systems (control)   work on higher level of complexity   support decision making processes

!

!

Office systems !  Real-time control systems ! 

Wolfram Webers

October, 2008

8

(

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

Informs and enables

Drives and sets goals Business Strategy

Where IS can help

What must be done

Information System Strategy Hardware capabilities

System requirements

Information Technology Strategy

Source: Bennett, McRobb, Farmer (2006)

Wolfram Webers

October, 2008

9

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



End-user’s perspective   “What system? Haven’t seen any system!”   “Might work, but it’s dreadful to use.”

!

!



Client’s perspective        

!

!

!

!



“If I’d known the real price,…” “It’s too late now, we needed it last April” “Now it works, but the installation…” “Everything’s changed now, we need a different system”

Developer’s perspective        

!

!

!

!

“We built what they said they wanted” “There wasn’t enough time to do it better” “We said it was impossible, but no-one listened” “The system’s fine, the users are the problem”

Wolfram Webers

October, 2008

10

)

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

Source: TimeKontor, Berlin, May 2001

Source: Larman – Applying UML and Patterns, p. 42

Wolfram Webers

October, 2008

11

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

Analysis is a collection of actions aiming to ensure that the envisioned system meets the goals !  Analysis is part of a development process !  We can define a process as an orchestration of actions/tasks with specific purposes and outcomes !  Methods will guide how to fulfill those tasks !  Methods can rely on the usage of specific tools and paradigms ! 

Wolfram Webers

October, 2008

12

*

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



Elicitation and Analysis   Sometimes called requirements elicitation or elicitation or

!

requirements discovery   Involves technical staff working with customers to discover the application domain, domain, the services that the system should provide and the system’s operational constraints   May involve end-users, managers, engineers involved in maintenan maintenance, ce, domain experts, trade unions, etc. These are called stakeholders

!

!

Wolfram Webers

October, 2008

14

+

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

Requirements definition and specification

Requirements validation

Process entry

Domain understanding

 

Requirements collection

Prioritization

Conflict resolution

Classification

Wolfram Webers

October, 2008

15

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



User Requirements   Statements in natural language plus diagrams of the results and qualities the user wants. Owned by the user.

!



System Requirements   Statements, diagrams, models describing what the system must do to achieve the user requirements. Owned by the developer.  developer. 

!



Requirements Specificatio Specification n   Can be seen as a contract between customer and developer.

!

Wolfram Webers

October, 2008

16

,

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

Should describe functional and nonfunctional requirements so that they are understandable understanda ble by the users of the system who don’t have detailed technical knowledge !  User requirements are defined using natural language, tables and diagrams !  Make use of domain specific language specific language ! 

Wolfram Webers

October, 2008

17

October, 2008

18

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

Order entry clerk !  Shipping and handling clerk





Salesperson Department supervisor !  Customer, who places an order ! 

Wolfram Webers

%

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

Express, what the system must do !  Serve as a basis for designing the system !  Must have a direct relationship to the user requirement



  They must show that the system solves the problem

!

May be used as part of the system contract !  System requirements may be expressed using system models ! 

Wolfram Webers

October, 2008

19

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

User Requirements

System Requirements

Description of the problem

Abstract solution

In user language

In developer language

Organized by goals

Organized by functions in a hierarchy or by objects

Subject: a type of user

Subject: the system or subsystem

Defines what the user gets

Defines what the system does

Owned by users

Owned by developers

Wolfram Webers

October, 2008

20

!"

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



Functional requirements

  Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.   Depend on the type of software, expected users and the type of system where the software is used   Functional user requirements may be high-level statements of what the system should do, but only functional system requirements should describe the system services in detail

!

!

!

Wolfram Webers

October, 2008

21

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



Non-functionall Requirements NFR) Non-functiona

  Statements about the quality of the services the system should provide or qualities of the system itself.   NFRs are highly depend on the domain in which the system is to be used   NFRs are not limited to soft soft qualities  qualities   As NFRs comprise qualities, they shall be expressed in a measurable measurable way  way

!

!

!

!

Wolfram Webers

October, 2008

22

!!

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

Non-functional requirements

Product requirements

Efficiency requirements

Reliability requirements

Usability requirements

Performance requirements

Organizational requirements

Portability requirements

Delivery requirements

Space requirements

External requirements

Interoperability requirements

Implementation requirements

Ethical requirements

Standards requirements

Legislative requirements

Privacy requirements

Safety requirements

Wolfram Webers

October, 2008

23

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



In principle requirements should be both complete and consistent   Complete

!

  They should include descriptions of all facilities required

!

  Consistent

!

  There should be no conflicts or contradictions in the descriptions of the system facilities

!



In practice, it is impossible to produce a complete and consistent requirements document Wolfram Webers

October, 2008

24

!$

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



In principle requirements should be traceable   Source traceability

!

  Links from requirements to stakeholders who proposed these requirements

!

  Requirements traceability

!

  Links between dependent requirements

!

  Design traceability

!

  Links from the requirements to the design

!



Every requirement shall be identifiable   Usually some indexing/numbering is used

!

Wolfram Webers

October, 2008

25

Wolfram Webers

October, 2008

26

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



Traceability matrix

D=Derived, R=Requires

!'

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

IEEE 1233:1998 for System Requirements Specifications !  Structured document



  Introduction   General system description   System capabilities, conditions, and constraints   System interfaces   Appendices   Index

!

!

!

!

!

!



Must be adopted to own purposes

Wolfram Webers

October, 2008

27

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

part 1

Wolfram Webers

October, 2008

28

!(

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

Requirements Team

Use Case Model

Requirements List

Project Initiation Document

Requirements capture and modeling

Interface Prototype

Initial System Architecture

Glossary

Wolfram Webers

October, 2008

29

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

Prototype Designer

Requirements Analyst

Project Initiation Document Elicit Requirements

Develop Prototypes

Interface Prototype

Glossary

Candidate Requirements Select Requirements

Requirements List

Evaluate Prototypes

Develop Use Cases Use Case Model

System Architect

Develop Architecture

Wolfram Webers

Initial System Architecture

October, 2008

30

!)

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



Use Cases are stories of using a software system to meet goals   Mechanism to capture user needs and system requirements   Simplicity and utility are key success factors: stakeholders have to be able to contribute to definition and evaluation of requirements   Use cases represent primarily functional requirements

!

!

!





Use Cases are primarily text documents, not diagrams UML defines a use case diagrams to illustrate names of the use cases and actors, and their relationship Wolfram Webers

October, 2008

31

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



UP encourages use-case driven development   Requirements are primarily recorded in use cases (Use-Case Model)

!

  Use cases are an important part of iterative planning (chose use case scenarios or entire use cases for an iteration)   Use case realization drives the design   Use cases influence the organisation of user manual

!

!

!



UP disciplines   Business Modelling: business use cases (context: large scale business process re-engineering)   Requirements: system use cases

!

!

Wolfram Webers

October, 2008

32

!*

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



Actor

  something with behaviour (person, computer system, organisation)   Primary actor: actor: has user goals fulfilled through using services of the SuD (= system under discussion)   Supporting actor: actor: provides a service to the SuD actor: has an interest in the behaviour of the use   Offstage actor: case

!

!

! !



Scenario (= use case instance):

  specific sequence of actions and interactions between actors and the system under discussion

!



Use Case: Case:

  collection of related (success or failure) scenarios

!



UP definition of a use case:

  „A set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor.“  

!

Wolfram Webers

October, 2008

33

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



Starting Event   When / in what context is the use case performed? What preconditions have to be given?

!



Sequence of activities

  What happens upon the starting event? – List all what?), ?), but don‘t focus on the relevant activities (what details (how (how?) ?)

!



Situation at the end   What activity and/or post-condition concludes the use case?

!

Wolfram Webers

October, 2008

34

!+

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



Guideline for finding the dominant level:   Focus on use cases on the level of Elementary Business Processes (EBP):   EBP is a task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state

!

!



Four steps:   Choose the system boundary   Identify the primary actors   For each identify their user goals   Define use cases that satisfy the user goals

!

!

!

!

Wolfram Webers

October, 2008

35

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



The system boundary could be   software application or hardware and software   a person using it or an entire organisation   boundary can be clarified by defining what is outside

!

!

!



The system boundary for a point-of-sale point-of-sale system:   The point-of-sale system itself   Everything outside of the system is outside the system boundary

!

!

  The cashier, payment authorization service, and so on

!

Wolfram Webers

October, 2008

36

!,

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



Reminder Questions to find actors and goals:   Who starts and stops the systems?   Who does user- and security-management?   Is there a monitoring process that restarts the system if it fails?   How are software updates handled? Push or pull update?   Who does system-administration?   Is „time“ an actor because the system does something in   response to a time event?   Who evaluates system activity and performance?   Who evaluates logs? Are they remotely retrieved?

!

!

!

!

!

!

!

!

!  ! 

Focus is on Primary Actors, not on Supporting Actors Be suspicious if no primary actors are external to the system Wolfram Webers

October, 2008

37

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



Identification of user goals is usually done in Identification workshops



Record the primary an actor-goal list actors and their goals in !  Actor-Goal list is part of the Vision artefact Actor

Goal

Cashier

process sales process rentals handle returns cash in cash out … start up shut down …

Manager

Wolfram Webers

October, 2008

38

!%

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



Define one EBP use case for each user goal   Name the use case similar to the user goal   Name the use case starting with a verb   Keep the user interface out and focus on actor intent

!

!

!



Common exception:   CRUD goals (Create, Retrieve, Update, Delete) are usually collapsed into one use case called „Manage <X>“

!



Need for communication and participation of stakeholders Wolfram Webers

October, 2008

39

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



Other UML Models used as result of the analysis:   diagrams forfor reflecting structural topics   Class Activity diagrams reflecting processes   Package diagrams for reflecting initial architectures

!

!

!

Wolfram Webers

October, 2008

40

$"

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 

Analysis Patterns can help us to determine structures or behavior !  Martin Fowler (AP, 2001):



  “Patterns are a starting point, not a destination”   “Models are not right or wrong, they are more or less useful”

!

!

Analysis Pattern are observed structures and/ or behaviors of previous work done !  Patterns are highly abstracted and need to be adopted ! 

Wolfram Webers

October, 2008

41

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



Example: Organizational Hierachies parent

1

 {hierarchy} 

Organization *

University Jönköping:Organization parent

JI JIB BS S:O :Org rga a niz niza a ttio ion n

JTH: JTH:Or Org ga an n iiza zati tio on

Wolfram Webers

October, 2008

42

$!

 

!"#$%#"%

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



Example: Extending patterns  {a compnany is the parent of divisions, which is the parent of departments} 

parent

1

 {hierarchy} 

Organization *

Company

Division

Department

Wolfram Webers

October, 2008

43

ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL  JÖ NK ÖP IN G UN IV ER SI TY 



Example: Party (abstraction of people and organization) parent

1

 {hierarchy}  Party

Party *

parent 1 Person

Organization

Person

 {hierarchy} 

Organization *

Wolfram Webers

October, 2008

44

$$

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close