• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Abstract Requirements Engineering 1.0
 

Abstract Requirements Engineering 1.0

on

  • 396 views

Ideas about Requirements Engineering

Ideas about Requirements Engineering

Statistics

Views

Total Views
396
Views on SlideShare
275
Embed Views
121

Actions

Likes
0
Downloads
3
Comments
0

2 Embeds 121

http://mkuegeler.tumblr.com 73
http://5deen.com 48

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Abstract Requirements Engineering 1.0 Abstract Requirements Engineering 1.0 Presentation Transcript

    • Abstract Requirements Engineering Draft 1.0 (12.06.2013) by Michael Kuegeler Munich Email: mkuegeler@gmail.com
    • Complexity
    • Application System D Media B View B Requirement Requirement YRequirement Z Media A Requirement X Role 1 Role 2 Business Owner Time System C Requirement View A Budget
    • Form follows Function
    • The centralized Approach Roles Views MediaSystem Application
    • Guide Lines • Consider multiple elements • Use formalized descriptions • Try out spatial visualization of requirements • Think about CRUD (Create, Read, Update, Delete) • Imagine Media • Define roles (Personas) • Regard scenario and process as related • Identify internal and external dependencies
    • A Case Structure Business Case Epic Story Scenario Scenario Story Scenario Scenario Epic Story Scenario Scenario Story Scenario Scenario 1 1.1 2 1.2 1.1.1 1.1.2 2.1 2.2 1.2.1 1.2.2 2.1.1 2.1.2 2.2.1 2.2.2 Layer B Layer A Layer C > Condition > > Condition > > Condition >
    • A Formalized Story I as Personas (Who) need a functionality (What) to achieve following business value (Why) What WhyWho Layer A Action ReadCreate Layer B Update Delete Media MailFile Layer C Voice Print OR OR OR OR OR OR
    • Case Template Business Case 1.1 Epic 1.1.1 Story 1.1.2 Story 1.1.3 Story 1.1.4 Story Persona Media: File Persona Persona Persona Action: Read Action: Write Action: Read Action: Read 1.2 Epic Media: Mail Media: Voice Media: Data
    • Multiple Sensors / Configuration • A user wants to connect (add) an additional sensor with his already paired starter kit. • A user wants to disconnect (delete) a sensor from his starter kit configuration. • A user wants to replace (update) a sensor because the current one is no longer working.
    • Case Template (Example) Business Case: Management of Multiple Sensors and Base Stations 1.1 Epic: Manage Multiple Sensors 1.1.1 Add a sensor 1.1.2 View sensor status 1.1.3 Remove a sensor 1.1.4 Replace a sensor End User (Martin) Media: Data End User (Martin) End User (Martin) End User (Martin) Action: Create Action: Read Action: Delete Action: Update 1.2 Epic: Manage Multiple Base Stations Media: Data Media: Data Media: Data Story Points: 8 Story Points: 5 Story Points: 13 Story Points: 13
    • Fibonacci Sequence 0 1 2 3 4 5 6 0 1 1 2 5 8 13 The next number is found by adding up the two numbers before it. Leonardo da Pisa, also called Fibonacci (* 1180? in Pisa; † after 1241? In Pisa)
    • Example: Estimation (Complexity) No effort, already realized0 = Implementation is well-known, commodity work5 = Implementation is known, however some effort required8 = Implementation is partly known, medium effort13 = Implementation is partly known, much effort21 = Implementation is almost unknown, research required34 =