Software Systems Requirements and Architecture SWEN440 Bob Kuehl - - PowerPoint PPT Presentation

• R. Kuehl/J. Scott Hawker
• p. 1

R I T

Software Engineering

Software Systems Requirements and Architecture

SWEN440 Bob Kuehl

• R. Kuehl/J. Scott Hawker
• p. 2

R I T

Software Engineering

Your Experience?

 ”The project's vision and scope are never clearly defined.  Customers are too busy to spend time working with analysts or developers

• n the requirements.

 User surrogates, such as product managers, development managers, user managers, or marketers, claim to speak for the users, but they don't accurately represent user needs.  Requirements exist in the heads of "the experts" in your organization and are never written down.  Customers claim that all requirements are critical, so they don't prioritize them.  Developers encounter ambiguities and missing information when coding, so they have to guess.  Communications between developers and customers focus on user interface displays and not on what the users need to do with the software.  Your customers sign off on the requirements and then change them continuously.  The project scope increases when you accept requirements changes, but the schedule slips because no additional resources are provided and no functionality is removed.  Requested requirements changes get lost, and you and your customers don't know the status of all change requests.  Customers request certain functionality and developers build it, but no one ever uses it.  The specification is satisfied, but the customer is not.”

Wiegers P. 5

• R. Kuehl/J. Scott Hawker
• p. 3

R I T

Software Engineering

Software Engineering Context

Problem Domain Requirements Architecture Design Implementation Test and Deployment Product or Service

>$ Cost Time >Value >Knowledge

Rework

Projects fail if $Rework > $Value Work >Complexity

What methodology = f (experience, environment, size)

This Course

<Risk

• R. Kuehl/J. Scott Hawker
• p. 4

R I T

Software Engineering

Rational Unified Process

• R. Kuehl/J. Scott Hawker
• p. 5

R I T

Software Engineering

Context

 Software requirements are the single most important element of project success

 Miss the requirements, the delivered project is wrong, no matter how technically magical  Requirements management drives project budget and schedule, which are common causes of project failure

 Software architecture is the foundational design response to software requirements

 Functional requirements  module decomposition, separation of concerns  Quality requirements  quality-specific design patterns and tactics

• R. Kuehl/J. Scott Hawker
• p. 6

R I T

Software Engineering

Types of Requirements

Business Requirements User Requirements System Requirements Business Rules Quality Attributes External Interfaces Constraints Functional Requirements Vision and Scope Document User Requirements Document Software Requirements Specification

Solid arrow – stored in Dotted arrow – origin of or influence

• R. Kuehl/J. Scott Hawker
• p. 7

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

• R. Kuehl/J. Scott Hawker
• p. 8

R I T

Software Engineering

Software Architecture Design Reference Model

Requirements:

• Domain functions
• Quality attributes
• Use cases

Architecture Drivers Subset Quality Attribute Scenarios Architecture Pattern “Catalog” Pattern and design tactics selection Module decomposition design Design decision analysis Architecture Design Documentation Architecturally Significant Requirements

• R. Kuehl/J. Scott Hawker
• p. 9

R I T

Software Engineering

Big Picture Views

 Product requirements and architecture are big- picture (holistic) views of the system

 Strategic  Abstract  Drive later development

• Detailed requirements and design elaborate

initial requirements and architecture design

• Details of technology choices and

programming, integration, and test issues

 There are multiple views of a single system

 No one view can capture the scope and complexity

• f a useful system

 Manage complexity, don’t avoid it

• R. Kuehl/J. Scott Hawker
• p. 10

R I T

Software Engineering

Software Engineering Roles

 Analyst – performs requirements engineering activities to specify and manage requirements  Architect – designs and documents a software architecture that satisfies system requirements

• R. Kuehl/J. Scott Hawker
• p. 11

R I T

Software Engineering

Requirements and Architecture Project

Application Domain

Developer Stakeholder (Team roles) Developer Stakeholder (Team roles)

Elicitation Review Feedback

• Requirements Artifacts
• Software Architecture Design
• Requirements Artifacts
• Software Architecture Design

Product Champion Product Champion