software requirements (advanced topics) “walking on water and developing software from a...

19
Software Requirements (Advanced Topics) “Walking on water and developing software from a specification are easy if both are frozen.” --Edward V Berard

Upload: julianna-jefferson

Post on 31-Dec-2015

215 views

Category:

Documents


0 download

TRANSCRIPT

Software Requirements

(Advanced Topics)

“Walking on water and developing software from a specification are easy if both are frozen.”

--Edward V Berard

Definition

Requirement – “A statement of a customer need or objective, or of a condition or capability that a product must possess to satisfy such a need or objective. A property that a product must have to provide value to a stakeholder.” [Wiegers. S/W Requirements, p 487]

Levels of Requirements

Two Distinct Activities

(Software Requirements)

(System Specifications)

Types of Requirements

Requirement Engineering

Requirements Development

Requirements Change Management

• Understand the problem or opportunity.• Determine the system behavior that will address the identified problem or opportunity.• Document the desired system behavior in a written specification• Validate understanding of requirements

• Manage changes to baselined software requirements.

Baselined Software Requirements

Requirements Development Steps

1. Define the project's vision and scope. This should make clear the problem or opportunity.

2. Understand business goals and objectives.3. Identify expected user classes4. Identify appropriate representatives from each user class (product

champion)5. Identify a set of goals for each user class. What do users in each class

need to accomplish?6. Develop and prioritize the main use cases for the system (architecturally

significant use cases). One approach is to identify all use cases but detail those with the highest priority first.

7. Analyze requirements. Organize and prioritize requirements. (e.g. Functional, Non-functional) Look for overlapping, conflicting, missing requirements, etc.

8. Develop analysis models as needed to clarify problem domain and/or requirements

9. Document requirements.10. Validate requirements with customers and users (or user

representatives)

Requirement Prioritization

• Prioritizing requirements is important. 64% of the features included in products are rarely or never used.

Actor-Goal ListActor Goal

Author Create quiz (MC, T/F, Essay questions)

Edit quiz

Make quiz available

Quiz taker Browse available quizzes

Add quiz to individual bookshelf

Delete quiz from individual bookshelf

Answer questions on quiz

Save partial results

Submit quiz

View bookshelf

User Stories

• “A user story is a brief description of functionality as viewed by a user or customer of the system.” [p 25, Agile Estimating and Planning]

• Example story card:

View Bookshelf

Quizzes can be in one of 5 states: not started, started not submitted, submitted and partially graded, graded. When viewing personal bookshelf of quizzes, users should be able to see the state of each quiz and be given options to take the next logical step with each quiz.

Use Case—Definition

• A use case is a narrative description of a goal-oriented interaction between the system under development and an external agent

• Includes the what:– User (Actor in Use Case Parlance)– Goal– Interaction

• But not the how:– Excludes User Interface Detail– Excludes Implementation Concerns

Another Example

UML Use Case Diagrams

System Under Development

Use CaseActor

Newspaper Web Site

Post article

Journalist

Reader

Authenticate user

Find and read article

<<include>>

<<include>>

Generic Form Example

Use Case Template

Title:

Actors:

Preconditions:

Postconditions:

Basic Flow / Main Success Scenario

Alternate Flow / Extensions

Open Issues

ExampleTitle: Search Web with suggested key words (Google Suggest)

Actors: Web User

Preconditions: Web user is at the search page

Basic Flow1. User begins to enter search phrase

2. As characters of search phrase are typed, the system responds with suggested search phrases that start with characters entered

3. The system enters the highest ranking suggested search phrase into the search box where the user is typing

4. User scrolls to desired suggested phrase

5. User initiates search

6. System responds with search results that match search phrase

Alternate Flows2a. There are no high ranking suggested search phrases for the characters the user has entered

1. The system gives no suggested search phrases

2. The user enters the remaining characters in the search phrase and control returns to step 5 in basic flow

4a. User decides to accept suggested search phrase in search box

1. User initiates search with suggested search phrase currently in search box

4b. User finishes entering original search phrase but doesn’t want to take system’s suggestion

1. User hits backspace to erase remaining suggested characters in search box

Open Issues1. How to decide the order or ranking of suggested search phrases.

Features

• The IEEE defines a feature as “A distinguishing characteristic of a software item (e.g., performance, portability, or functionality).”

• Features are more general, and sometimes finer grained, than use cases.

• Even though features are more abstract than use cases, elaborating use cases often identifies new features.

• Features capture requirements that aren’t conveniently captured via use cases.

• Projects are usually planned in terms of features. For example, the goal of iteration #1 might be to implement a certain collection of features.

Example Features

• The system shall offer the ability to create multiple choice, multiple answer, true/false and essay type questions.

• The system shall offer, within certain domains, pre-defined questions for authors to choose from.

• The system shall prevent unauthorized eavesdropping on answers. For example, a company should be able to post a quiz for qualifying applicants for an advanced programming position without concern that an “industrious” applicant might surreptitiously obtain the answers.

Requirements Deliverable

• Categories of users (roles).• List of goals associated with each role• Use cases for goals within scope (this semester)• User stories for goals outside of scope (this semester)• Features• Non-functional requirements, grouped by:

– Those important to users– Those important to developers

• Assumptions• Constraints

Project Planning

• Once you understand what key features are needed and can imagine at least one solution architecture, you can begin to schedule the work.