Software Requirements Engineering Introduction R. Kuehl/J. Scott - - PowerPoint PPT Presentation

software requirements engineering introduction
SMART_READER_LITE
LIVE PREVIEW

Software Requirements Engineering Introduction R. Kuehl/J. Scott - - PowerPoint PPT Presentation

Software Requirements Engineering Introduction R. Kuehl/J. Scott Hawker p. 1 R I T Software Engineering Topics Set the context for requirements engineering Requirements engineering as knowledge acquisition and transformation


slide-1
SLIDE 1
  • R. Kuehl/J. Scott Hawker
  • p. 1

R I T

Software Engineering

Software Requirements Engineering Introduction

slide-2
SLIDE 2
  • R. Kuehl/J. Scott Hawker
  • p. 2

R I T

Software Engineering

Topics

 Set the context for requirements engineering  Requirements engineering as knowledge acquisition and transformation  Introduce terms, concepts, and activities of requirements engineering  Why engineer requirements?

slide-3
SLIDE 3
  • R. Kuehl/J. Scott Hawker
  • p. 3

R I T

Software Engineering

Problem and Solution

What? How?

Computer Science Mathematics Natural Sciences Software Engineering Liberal Arts

(Requirements Engineering)

Problem Solution

slide-4
SLIDE 4
  • R. Kuehl/J. Scott Hawker
  • p. 4

R I T

Software Engineering

Requirements Engineering as a Human Activity System

“Requirements engineering draws on cognitive and social sciences to provide both theoretical grounding and practical techniques for eliciting and modeling requirements”

 Psychology - an understanding of the difficulties people may have in communicating their needs  Anthropology - a methodological approach to observing human activities to help understand how computer systems may help or hinder those activities  Sociology - an understanding of the political and cultural changes caused by a new system.  Linguistics – communication and the use of language  Philosophy – understanding stakeholder world view, beliefs, goals, motivations, logic, agreements, what is knowable, etc.

slide-5
SLIDE 5
  • R. Kuehl/J. Scott Hawker
  • p. 5

R I T

Software Engineering

Requirements Engineering Requires Creativity

 Creativity - production of something original and useful  The creative process:

 Fact finding – gain domain knowledge  Problem finding – anticipate all possible pitfalls and issues  Idea finding – generate as many ideas as possible  Solution finding – which ideas are the most effective and value adding  Develop plan of action

slide-6
SLIDE 6
  • R. Kuehl/J. Scott Hawker
  • p. 6

R I T

Software Engineering

“The Five Orders of Ignorance”

 Software is a medium for the storage of knowledge  The product is the stored knowledge; analogous to a book  The key challenge is knowing what to build - acquiring the necessary knowledge  So software development produces products as a knowledge- acquiring activity  Hacking is a process of acquiring knowledge as you write the code  The final product is contaminated with the legacy of the code that is changed or discarded along the way, the “unknowledge”.  Prototyping is a name for following this process intentionally.

[Armour , CACM, 10/2000, Vol 43, No 10, P. 17]

slide-7
SLIDE 7
  • R. Kuehl/J. Scott Hawker
  • p. 7

R I T

Software Engineering

“The Five Orders of Ignorance”

0th Order I know enough to build the software I have the answer 1st Order Lack of knowledge - I know I don’t know something and can do something about it I have the question and it can be answered 2nd Order Lack of awareness - I don’t know that I don’t know The real problem – I don’t have the answer or the question; where most projects begin 3rd Order Lack of process – I don’t know an effective way to find out I don’t know that I don’t know Find and use methods to frame and eventually answer the question; requirements engineering! 4th Order Meta ignorance – I don’t know about the five orders of ignorance

Now you do! If software development is the acquisition of knowledge, it can also be viewed as the reduction or elimination of ignorance.

slide-8
SLIDE 8
  • R. Kuehl/J. Scott Hawker
  • p. 8

R I T

Software Engineering

Requirements Engineering as Modeling

 Systems and users do work, sometimes in collaboration, sometimes independently  Requirements engineering is about how to discover and document the work  Abstraction hierarchy – system -> features -> functions -> tasks -> subtasks -> actions

slide-9
SLIDE 9
  • R. Kuehl/J. Scott Hawker
  • p. 9

R I T

Software Engineering

Requirements Engineering as Knowledge Acquisition, Transformation, and Communication

Problem Domain, Stakeholder and User Goals and Needs Analysis Models Design Models and Solution Understanding Software Requirements Specification

Stakeholders, Customers, Users Requirements Analyst Software Engineer

What How

Functional capabilities Non-functional quality attributes Constraints or conditions Software architecture

slide-10
SLIDE 10
  • R. Kuehl/J. Scott Hawker
  • p. 10

R I T

Software Engineering

Communication

slide-11
SLIDE 11
  • R. Kuehl/J. Scott Hawker
  • p. 11

R I T

Software Engineering

What is a Requirement?

 Requirement [Merriam-Webster On-Line Dictionary]

 a : something wanted or needed : necessity  b : something essential to the existence or

  • ccurrence of something else : condition

 Software requirement is a condition or capability [IEEE-STD-610.12-1990 Software Engineering Glossary]  Needed by a user to solve a problem or achieve an objective  Met or possessed by a system to satisfy formally imposed documents such as specifications or standards

slide-12
SLIDE 12
  • R. Kuehl/J. Scott Hawker
  • p. 12

R I T

Software Engineering

Types of Requirements

 Business – business objectives, the “business case”  Business rules – policy, guideline, regulation, algorithm  User – goals and tasks for a class of user; HCI  Quality Attributes – non-functional level of service  System – high level requirements for the system at large  External Interface – interfaces to users and/or other systems  Constraints – development choice restrictions  Functional – behavior the system must exhibit to satisfy user and business requirements

slide-13
SLIDE 13
  • R. Kuehl/J. Scott Hawker
  • p. 13

R I T

Software Engineering

Goals vs. Requirements?

 System functions and features must address goals  Tasks are the means to the end (goals)  Goals are the motivation for observed behaviors

 Goals drive usage behavioral patterns

slide-14
SLIDE 14
  • R. Kuehl/J. Scott Hawker
  • p. 14

R I T

Software Engineering

Why Engineer Requirements?

 The most significant contributors to project failure relate to requirements (Standish Group’s CHAOS Reports)

 Most failed projects fail due to changing customer requirements

 Meeting your project’s requirements defines success  We can engineer a higher probability of success

slide-15
SLIDE 15
  • R. Kuehl/J. Scott Hawker
  • p. 15

R I T

Software Engineering

Why Software Fails

  • Unrealistic or unarticulated project goals

 Inaccurate estimates of needed resources

  • Badly defined system requirements

 Poor reporting of the project's status  Unmanaged risks

  • Poor communication among customers, developers,

and users

 Use of immature technology  Inability to handle the project's complexity  Sloppy development practices  Poor project management  Stakeholder politics  Commercial pressures

http://spectrum.ieee.org/computing/software/why-software-fails

slide-16
SLIDE 16
  • R. Kuehl/J. Scott Hawker
  • p. 16

R I T

Software Engineering

A Notable Example of Requirements Failure

(CNN) -- NASA lost a $125 million Mars orbiter because a Lockheed Martin engineering team used English units of measurement while the agency's team used the more conventional metric system for a key spacecraft operation, according to a review finding released Thursday. The units mismatch prevented navigation information from transferring between the Mars Climate Orbiter spacecraft team in at Lockheed Martin in Denver and the flight team at NASA's Jet Propulsion Laboratory in Pasadena, California.

slide-17
SLIDE 17
  • R. Kuehl/J. Scott Hawker
  • p. 17

R I T

Software Engineering

“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, … ….. No other part of the work so cripples the resulting system if done

  • wrong. No other part is more difficult to rectify later.”

[Brooks, The Mythical Man-Month 1995]

slide-18
SLIDE 18
  • R. Kuehl/J. Scott Hawker
  • p. 18

R I T

Software Engineering

Ethical Considerations

 Software engineering ethics starts with requirements  Consider questions such as …

 Public and market value  Unintended consequences, especially of scale  Quality  User diversity, cultural values  Safety  Privacy  Practicality within constraints  Legal compliance  ….

slide-19
SLIDE 19
  • R. Kuehl/J. Scott Hawker
  • p. 19

R I T

Software Engineering

Requirements Engineering Process Frameworks

 We will survey techniques from a variety of sources  We will utilize elements of the Unified Modeling Language (UML) from the Rational Unified Process (RUP)  It is essential to learn some “systematic, disciplined, quantifiable approaches” to engineering of software requirements  the “classics” like basic arithmetic

UML reference – “UML 2 Toolkit” @RIT Libraries 24/7 Books

slide-20
SLIDE 20
  • R. Kuehl/J. Scott Hawker
  • p. 20

R I T

Software Engineering

What About Agile Methodologies?

“Everyone is using agile style incremental, iterative development now; UML is just too heavy” “Just outline requirements and code”  Agile techniques won’t fit every project, especially for large and complex systems  Requirements engineering concerns and techniques still apply  As we discuss the classics, we will periodically consider agile style considerations Note: Some knowledge of agile methods is assumed

slide-21
SLIDE 21
  • R. Kuehl/J. Scott Hawker
  • p. 21

R I T

Software Engineering

Vocabulary

 Domain (application)

 The target area of interest, usually the business context  E.g., health care, scientific research, a product market, an enterprise sales department

 Business

 The sponsoring institution – profit, non-profit, commercial (external products and systems), enterprise (internal products and systems)

 Problem

 A business issue to be resolved or objective to be accomplished by the solution

 Solution

 The system or product that addresses the problem requirements

 System

 The inputs, processing, and outputs comprising the solution  “System” will be used generally as the abstraction for what is to be built

slide-22
SLIDE 22
  • R. Kuehl/J. Scott Hawker
  • p. 22

R I T

Software Engineering

Vocabulary (cont)

 Product

 The specific incarnation of the solution – a system, subsystem, application

 Project

 All of the activities managed by some process necessary to create a finished system or product solution to satisfy the domain problem

 User

 The individual (or external system) that interacts with the system features

 Stakeholder

 Individuals (or external systems) that have some vested interest in the success of the system  E.g., management, users, customers, developers, service providers, etc.  Customer  The individual who pays for and receives the completed system or product

slide-23
SLIDE 23
  • R. Kuehl/J. Scott Hawker
  • p. 23

R I T

Software Engineering

Sources

 Karl Wiegers, Software Requirements, 2nd Edition, Microsoft Press, 2003.  Eclipse Process Framework project – OpenUP White Paper (http://www.eclipse.org/epf/general/OpenUP.pdf )  Unified Process for Education (UPEDU –Yoopeedoo) (http://www.yoopeedoo.org/ then navigate the UPEDU link)  Data Analysis Center for Software (DACS) (http://www.dacs.dtic.mil/) Requirements Management Gold Practice (http://www.goldpractices.com/practices/mr/index.php)  IEEE-STD-830-1998 Recommended Practice for Software Requirements Specifications  IEEE-STD-610.12-1990 Software Engineering Glossary  Software Engineering Body of Knowledge (http://www.swebok.org/)  Brooks, Fred P., The Mythical Man-Month, 20th Anniversary Edition, Addison Wesley, 1995.  [Standish 1995] Standish Group, The Standish Group Report: Chaos, 1995, http://spinroot.com/spin/Doc/course/Standish_Survey.htm.  See also http://www.standishgroup.com/  Armour, Phillip G., The Five Orders of Ignorance, CACM, 10/2000, Vol 43, No 10, P. 17-20.