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 classes 4.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 List ActorGoal AuthorCreate quiz (MC, T/F, Essay questions) Edit quiz Make quiz available Quiz takerBrowse 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 Case Actor Newspaper Web Site Post article Journalist Reader Authenticate user Find and read article > Generic FormExample

Use Case Template Title: Actors: Preconditions: Postconditions: Basic Flow / Main Success Scenario Alternate Flow / Extensions Open Issues

Example Title:Search Web with suggested key words (Google Suggest) Actors: Web User Preconditions: Web user is at the search page Basic Flow 1.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 Flows 2a. 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 Issues 1. 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.