CS- Software Engineering. Homework

Gathering Requirements

Understanding what the stakeholders want!

Stakeholder: anyone who benefits from the system!

One of the most difficult parts of engineering!

Why?!

Impact: mistakes here can obviate the work products at any point in the process

Requirements Engineering

A set of steps/techniques that!

1. Facilitate understanding!

2. Set groundwork for modeling and design!

Some techniques can blend together!

Some steps may be unnecessary for small projects

RE Steps (Actions) Inception!

Elicitation!

Elaboration!

Negotiation!

Specification!

Validation!

Requirements Management

Inception

Goals:!

1. Identify stakeholders!

2. Understand need for the software!

3. Establish general scope of software!

4. Produce an initial description (product request)

Inception

Identify the stakeholders!

Who wants the software and who will use it?!

What are the benefits of the software?!

What are the alternatives?

Inception

Problem(s) and solution perception!

What are the problems that software will solve?!

Where will it be used (the environment)?!

What does the solution look like?!

Are there special constraints? (e.g., web app, external interfaces, security, business logic)

Inception Notes

Work with the SHs!

Stay helpful!

Learn the domain!

Ask SHs if anyone should be involved!

Promote success through good communication

Inception Example

A big part of our business involves insuring properties. Our customers work through our insurance agents or data entry support personnel to add and cancel coverage on properties.! For some of our larger customers, a database manager needs to be able to import customer data from their property management systems directly into our software.

Elicitation

Interview all SHs!

For software objectives, constraints, how it is used, etc.!

Goals!

Produce a preliminary set of requirements

Elicitation

Inception produces a basic description!

May have ambiguity, conflict, errors, etc.!

Elicitation distills out the first draft of requirements!

SHs make lists of objects, services, and constraints!

Lists are combined and discussed

Reqs. Distillation

Per SH/user role!

List the objects, services, and constraints!

Then look for commonality and conflicts between lists!

Begin to merge lists but keep track of SH/user info

Example for Property Coverage Services

SH/User Role: Insurance Agent! can add a property for coverage! can cancel a property’s coverage

SH/User Role: Data Entry! can add coverage! can cancel coverage

SH: Database Manager! can import coverage data

RE Example We want a software program so that our users can publish and read technical articles concerning basket weaving. ! ! New users have to fill out a registration form and pick a user name and password. Users can suspend their account at any time, which suppresses further notifications of new articles, and can resume at any time.! ! Certain members can become authors by requesting and being approved by an admin. A similar request and approval process is also used for reviewers. Authors cannot be reviewers.! ! Articles are due on the 10th of each month and then are reviewed by the reviewers. Authors submit their articles for review. An author may recall their article at any point before the article is published. Once an article is submitted for review, reviewers will review the article and approve or reject it for publishing. Articles must be approved or rejected by the 15th of each month. Approved articles will then be published on the 16th by the system admin.! ! All members can comment on any article at any time. Members can also delete any comment he/she has made. All users are notified on the 16th when new articles are available.

RE Example

1. Identify Stakeholders/user types!

2. Assemble definitions (and identify Objects)!

3. Extract Use Cases (i.e., Functional Requirements) and constraints (rules, restrictions, security properties, etc.)!

4. Group Use Cases by user type!

Are there any problems that need clarification/resolution?

Quality Function Deployment

System for classifying requirements to try to max customer satisfaction!

Normal: customer’s stated reqs. (e.g., add coverage)!

Expected: implicit (e.g., security and access control, performance, stability, user friendly)!

Exciting: surpass customer’s expectations (bonus reqs)!

Use throughout process as “customer’s voice” for priorities

Elaboration

Digs into the details of the requirements!

Goals!

Produce a more precise and detailed set of requirements!

A deeper understanding of the software’s purpose

Usage Scenarios

Plain text perspective of a particular service for a single user (or actor)!

E.g., Data Entry user adding coverage!

Actor: an entity external to the system that interacts with the system for the particular use/behavior to be described

Writing a Usage Scenario

Who are the actors?!

What are the pre- and postconditions?!

What are the main tasks to be performed by actors?!

What are exceptions and alternatives to actions?

Usage Scenario Example 1. Data entry person is logged into the software and selects Add

Coverage from the menu. (can have alt info here)!

2. Software creates a blank coverage form where the user types in the location address, zip code, value to insure, and date of coverage.!

3. Client’s main zip code database fills in city and county information automatically. (can have alt info here)!

4. If zip code, insured value, and coverage dates are ok, the user clicks an Add Coverage button.

Requirements Models

Provide a visual description of the software’s requirements!

Can help many different SHs digest info easier!

And pick out conflicts, errors, 0missions, etc.!

Can use Use Case, Activity, Class, State diagrams

Use Cases Something an actor wants to do with the system!

Similar to usage scenarios but more organized!

Make a Use Case diagram!

For each functional group of services!

Identify the services and actors involved!

Are there external interactions? (events, actors, reports)

UC Diagram Example Property Coverage (function)

Data Entry

Agent

Database Manager

UC02: Cancel Property Coverage

UC01: Add Property Coverage

UC03: Import Property Data

Zip Code Database

Customer Database

Use Case Detail Name and ID!

Brief Description!

Actors Involved!

Preconditions!

Main Flow (the steps involved the normal case)!

Postconditions!

Alternative flows

Use Case Example Use Case

Name AddPropertyCoverage

ID UC01

Description Adds a property and coverage to the system

Actors Agent, Data Entry, DB Manager (users); Zip code db

Preconditions Actor logged in and has access to function

Main Flow

1. user selects Add Coverage function# 2. blank property coverage form appears# 3. user enters address, zip, insured value, coverage dates# 4. zip code db fills in city, state, and county# 5. user submits property coverage to system

Postconditions new property coverage records created#user returns to menu choices

Alternative Flows

NotLoggedIn during Preconditions# NoAccess after Step 1# InvalidZipCode after Step 3# InvalidInsuredValue before Step 5# InvalidCoverageDate before Step 5

Alternative Flow Example

Alternative Flow

Name InvalidZipCode

ID UC02

Description The specified zip code is not in zip code db

Actors Agent, Data Entry, DB Manager (users); Zip code db

Preconditions zip code db cannot find zip code

Main Flow 1. system displays invalid zip code message# 2. clears city and county fields# 3. returns to calling UC

Postconditions city and county fields blank

Use Case Modeling Useful when!

System has a lot of services/functional reqs.!

and/or a lot of actors involved in the functions!

Not so useful when!

System has few functional reqs.!

and/or few actors/interfaces

Analysis Patterns

Provide reusable solutions for requirements analysis for certain application domains!

Already have main requirements for project!

Cites advantages and limitations!

Suggest transformation for reqs into design models!

Patterns are helpful, but not a perfect and brainless solution

Negotiation

Necessary when !

Requirements have conflicts between SHs!

and/or function/budget/time constraint issues!

Stay helpful, open, and professional

Validation Detects conflicts, omissions, errors in requirements!

Check requirements by asking!

Does requirement add value to the system?!

Is it clear? Does it conflict with other reqs?!

Can it be traced to at least 1 SH?!

Is it feasible? Are there dependencies?!

How to test?

Requirements Engineering Summary

RE is all about understanding what the client wants!

And preparing for estimating and design work!

Talk to all SHs and get their requirements!

Condense and visually model the requirements!

Check for and resolve conflicts, errors, omissions!

Double-check (and start creating acceptance tests)

Example Specifications Plain language description of scope (services and constraints)!

List of stakeholders!

Condensed list of services grouped by function category!

UC diagram based on list and UC details for all services!

Flow and Object diag. for important objects and services!

Glossary

Object Example Object: Property Coverage! Address (long text)! City (text)! County (text)! State (short text)! Zip Code (U.S. 10 digit)! Coverage Insured Value (currency)! Coverage Effective Date (date, no time)! Coverage Expiration Date (date, no time)

Glossary Example

Property: a physical location identified by address, city, state, county, and zip code!

Coverage: insurance placed for a Property; needs both an insured amount of coverage and coverage period!

Effective Date: date coverage starts!

Expiration Date: date coverage ends

Good Quote Kotaku interview with Feargus Urquhart, CEO of Obsidian Entertainment, regarding “failure” of Alpha Protocol:

“ T he y d id n ' t ha v e a n y s o r t o f g a m e s p e c i fi ca t i o n d o c u m e n t , Urquhart said, which is now something they require for all of their games: a listed, documented set of guidelines for exactly how a game will be designed and developed. They also didn't determine exactly who they were making the game for—action players? RPG fans? shooter addicts?—which Urquhart said was a serious detriment.”

Big League Specs

page 123 in Pressman textbook