csce 431 requirements n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
CSCE 431: Requirements PowerPoint Presentation
Download Presentation
CSCE 431: Requirements

Loading in 2 Seconds...

play fullscreen
1 / 80

CSCE 431: Requirements - PowerPoint PPT Presentation


  • 129 Views
  • Uploaded on

CSCE 431: Requirements. Some material from B. Meyer, M. Oriol , B. Schoeller , ETH Zurich. Outline. Motivation Ethics Overview of Requirements Task Recognizing Good Requirements Standards and Methods Requirements Elicitation About UML. Requirements Are Important.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'CSCE 431: Requirements' - zyta


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
csce 431 requirements

CSCE 431: Requirements

Some material from B. Meyer, M. Oriol, B. Schoeller, ETH Zurich

outline
Outline
  • Motivation
  • Ethics
  • Overview of Requirements Task
  • Recognizing Good Requirements
  • Standards and Methods
  • Requirements Elicitation
  • About UML

CSCE 431 Requirements

requirements are important
Requirements Are Important

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, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.

  • Fred Brooks, No Silver Bullet – Essence and Accident in Software Engineering, IEEE Computer, vol. 20, no. 4, April 1987, pp. 10-19.

CSCE 431 Requirements

software risk
Software Risk
  • Barry Boehm, Software Engineering Economics, Prentice Hall, 1981

CSCE 431 Requirements

some statistics on requirements
Some Statistics on Requirements
  • 80% of interface faults and 20% of implementation faults due to requirements (Perry & Stieg, 1993)
  • 48% to 67% of safety-related faults in NASA SW systems due to misunderstood HW interface specifications, of which 2/3 are due to requirements (Lutz, 1993)
  • 85% of defects due to requirements, of which 49% are incorrect assumptions 29% omitted requirements 13% inconsistent requirements (Young, 2001).
  • Requirements cause a lot of problems!

CSCE 431 Requirements

outline1
Outline
  • Motivation
  • Ethics
  • Overview of Requirements Task
  • Recognizing Good Requirements
  • Standards and Methods
  • Requirements Elicitation
  • About UML

CSCE 431 Requirements

ethical view
Ethical View
  • When customers present ideas that need system solutions, developers have an ethical and professional obligation to help customers define their problem.
  • You must build the best solution to the customer’s problem, even if the customer does not yet understand how to ask for it.
    • Bernstein & Yuhas
    • More on professional ethics in future lecture

CSCE 431 Requirements

outline2
Outline
  • Motivation
  • Ethics
  • Overview of Requirements Task
  • Recognizing Good Requirements
  • Standards and Methods
  • Requirements Elicitation
  • About UML

CSCE 431 Requirements

definitions
Definitions
  • A requirement is a statement of desired behavior for a system
  • The requirements for a system are the collection of all such individual requirements
  • Requirements process has two activities:
    • Requirements elicitation — definition of the system in terms understood by the customer and/or user
      • Agile process – user stories, customer on site
    • Requirements analysis — definition of the system in terms understood by the developer

CSCE 431 Requirements

goals of requirements phase
Goals of Requirements Phase
  • Understand the problem or problems that the eventual software system, if any, should solve
  • Prompt relevant questions about the problem and system
  • Provide basis for answering questions about specific properties of the problem and system
  • Decide what the system should do
  • Decide what the system should not do
  • Ascertain that the system will satisfy needs of its stakeholders
  • Provide basis for development of the system
  • Provide basis for validation and verification (especially testing) of the system
    • B. Meyer, Object-Oriented Software Construction

CSCE 431 Requirements

products of requirements
Products of Requirements
  • Requirements document
  • Development plan
  • Validation and verification plan (test plan)

CSCE 431 Requirements

how much effort
How Much Effort?
  • Should expect to allocate 15-30% of total project effort on requirements
  • Seems like a lot, but this phase is the source of many project failures
  • Remember that only 40-60% of requirements are known during requirements elicitation
    • Rest are emergent requirements

CSCE 431 Requirements

stakeholders
Stakeholders
  • One of the first phases is to identify stakeholders
  • Suggestions of groups to think about:
    • Clients
    • Customers
    • Clients’ and customer’s customers
    • Users
    • Domain experts
    • Legal experts
    • Purchasing agents
    • Software developers
    • Software project managers
    • Software documenters
    • Trainers
    • Consultants

CSCE 431 Requirements

components of requirements
Components of Requirements
  • Domain properties
    • Assumptions that are true in the domain
  • Functional requirements
  • Non-functional requirements
    • Reliability
    • Security
    • Accuracy of results
    • Time and space performance
    • Portability
    • Others?

CSCE 431 Requirements

roles of domain properties vs requirements
Roles of Domain Properties vs. Requirements
  • Requirement R:
    • “The database shall only be accessible to authorized personnel”
  • Domain Properties D:
    • Authorized personnel have passwords
    • Passwords are never shared with non-authorized personnel
  • Specification S:
    • Access to the database shall only be granted after the user enters an authorized password
  • S, DR
  • But what if domain assumptions are wrong?
  • Steve Easterbrook, 2008

CSCE 431 Requirements

domain assumption
Domain Assumption?

CSCE 431 Requirements

outline3
Outline
  • Motivation
  • Ethics
  • Overview of Requirements Task
  • Recognizing Good Requirements
  • Standards and Methods
  • Requirements Elicitation
  • About UML

CSCE 431 Requirements

quality goals for requirements
Quality Goals for Requirements
  • Correct
  • Complete
  • Consistent
  • Unambiguous
  • Traceable
  • Modifiable
  • Verifiable
  • Prioritized

830-1998 — IEEE Recommended Practice for Software Requirements Specifications

CSCE 431 Requirements

difficulties
Difficulties
  • Natural language and its imprecision
  • Formal techniques and their abstraction
  • Users and their vagueness
  • Customers and their demands (or managers/marketing/sales)
  • The rest of the world and its complexity
  • And things change during the project

CSCE 431 Requirements

bad requirements example
Bad Requirements, Example

NOT SO GOOD

The Background Task Manager shall provide status messages at regular intervals of not less than 60 seconds.

BETTER

The Background Task Manager (BTM) shall display status messages in a designated area of the user interface.

The messages shall be updated every 60 ± 10 seconds after background task processing begins.

The messages shall remain visible continuously.

Whenever communication with the background task process is possible, the BTM shall display the percent completed of the background task.

CSCE 431 Requirements

bad requirements another
Bad Requirements, Another

NOT SO GOOD

The XML Editor shall switch between displaying and hiding non-printing characters instantaneously.

BETTER

The user shall be able to toggle between displaying and hiding all XML tags in the document being edited with the activation of a specific triggering mechanism. The display shall change in ≤ 0.1 seconds.

CSCE 431 Requirements

bad requirements another1
Bad Requirements, Another

NOT SO GOOD

The XML parser shall produce a markup error report that allows quick resolution of errors when used by XML novices.

BETTER

After the XML Parser has completed parsed a file, it shall produce an error report that contains the line number and text of any XML errors found in the parsed file and a description of each error found.

If no parsing errors are found, the parser shall not produce an error report.

CSCE 431 Requirements

bad requirements one more
Bad Requirements, One More

NOT SO GOOD

The editor shall not offer search and replace options that could have disastrous results.

BETTER

The editor shall require the user to confirm global text changes, deletions, and insertions that could result in data loss.

The application shall provide a multi-level undo capability limited only by the system resources available to the application.

CSCE 431 Requirements

a balancing act
A Balancing Act
  • One should not over-specify
    • == committing too early to a specific implementation
  • One should not under-specify
    • == leaving some parts of the problem missing

CSCE 431 Requirements

a simple problem
A Simple Problem

NAUR’S PROBLEM STATEMENT

Given a text consisting of words separated by BLANK or by NL (new line) characters, convert it to a line-by-line form in accordance with the following rules:

Line breaks must be made only where the given text has BLANK or NL;

Each line is filled as far as possible as long as

No line will contain more than MAXPOS characters.

  • Peter Naur, Programming by Action Clusters, BIT, vol. 9, no. 3, pp. 250-258

CSCE 431 Requirements

improved specification
“Improved” Specification

The program’s input is a stream of characters whose end is signaled with a special end-of-text character, ET. There is exactly one ET character in each input stream. Characters are classified as:

  • break characters—BL (blank) and NL (new line);
  • nonbreak characters—all others except ET;
  • the end-of-text indicator–ET.

A word is a nonempty sequence of nonbreak characters. A break is a sequence of one or more break characters. Thus, the input can be viewed as a sequence of words separated by breaks, with possibly leading and trailing breaks, and ending with ET.

The program’s output should be the same sequence of words as in the input, with the exception that an oversize word (i.e., a word containing more than MAXPOS characters, where MAXPOS is a positive integer) should cause an error exit from the program (i.e., a variable, Alarm, should have the value TRUE). Up to the point of an error, the program’s output should have the following properties:

  • A new line should start only between words and at the beginning of the output text, if any.
  • A break in the input is reduced to a single break character in the output.
  • As many words as possible should be placed on each line (i.e., between successive NL characters).
  • No line may contain more than MAXPOS characters (words and BLs).

J. B. Goodenough and S. Gerhart,Towards a Theory of Test: Data Selection Criteria,

Current Trends in Programming Methodology, pp 44–79, Prentice Hall, 1977

CSCE 431 Requirements

meyer s analysis
Meyer’s Analysis
  • The following discussion is based on Bertrand Meyer’s analysis of the above specifications in On Formalism in Specifications, IEEE Software, pp. 6-26, Jan. 1985
  • His definition of specification:
    • Precise definition of the tasks to be performed by the system
  • Do not confuse with requirements, which are a natural-language definition of the system objectives

CSCE 431 Requirements

seven sins of the specifier
Seven Sins of the Specifier
  • Noise
    • Irrelevant information, redundancy, remorse (restriction at use, not definition, of an element)
  • Silence
    • Feature exists, but not discussed
  • Over-specification
    • Specification of a solution to the problem, not the problem
  • Contradiction
  • Ambiguity
  • Forward reference
  • Wishful thinking
    • Feature definition, for which candidate solutions cannot be realistically validated

CSCE 431 Requirements

noise
Noise

The program’s input is a stream of characters whose end is signaled with a special end-of-text character, ET. There is exactly one ET character in each input stream.Characters are classified as:

  • break characters—BL (blank) and NL (new line);
  • nonbreak characters—all others except ET;
  • the end-of-text indicator–ET.

A word is a nonempty sequence of nonbreak characters. A break is a sequence of one or more break characters. Thus, the input can be viewed as a sequence of words separated by breaks, with possibly leading and trailing breaks, and ending with ET.

The program’s output should be the same sequence of words as in the input, with the exception that an oversize word (i.e., a word containing more than MAXPOS characters, where MAXPOS is a positive integer) should cause an error exit from the program (i.e., a variable, Alarm, should have the value TRUE). Up to the point of an error, the program’s output should have the following properties:

  • A new line should start only between words and at the beginning of the output text, if any.
  • A break in the input is reduced to a single break character in the output.
  • As many words as possible should be placed on each line (i.e., between successive NL characters).
  • No line may contain more than MAXPOS characters (words and BLs).

CSCE 431 Requirements

remorse
Remorse

The program’s input is a stream of characters whose end is signaled with a special end-of-text character, ET. There is exactly one ET character in each input stream. Characters are classified as:

  • break characters—BL (blank) and NL (new line);
  • nonbreak characters—all others except ET;
  • the end-of-text indicator–ET.

A word is a nonempty sequence of nonbreak characters. A break is a sequence of one or more break characters. Thus, the input can be viewed as a sequence of words separated by breaks, with possibly leading and trailing breaks, and ending with ET.

The program’s output should be the same sequence of words as in the input, with the exception that an oversize word (i.e., a word containing more than MAXPOS characters, where MAXPOS is a positive integer) should cause an error exit from the program (i.e., a variable, Alarm, should have the value TRUE). Up to the point of an error, the program’s output should have the following properties:

  • A new line should start only between words and at the beginning of the output text, if any.
  • A break in the input is reduced to a single break character in the output.
  • As many words as possible should be placed on each line (i.e., between successive NL characters).
  • No line may contain more than MAXPOS characters (words and BLs).

CSCE 431 Requirements

silence
Silence
  • The “obvious” easily forgotten
  • In the example:
    • line never defined, except in the remorseful sequence of characters “between successive NL characters.”
      • Are the NL characters part of the line?
      • Are the first and the last lines “lines”?
    • Behavior of NL relies on contextual knowledge of a particular encoding (or an OS)
  • Alarm should be set to TRUE in one case, but nothing else is said about it

CSCE 431 Requirements

contradictions
Contradictions

The program’s input is a stream of characters whose end is signaled with a special end-of-text character, ET. There is exactly one ET character in each input stream. Characters are classified as:

  • break characters—BL (blank) and NL (new line);
  • nonbreak characters—all others except ET;
  • the end-of-text indicator–ET.

A word is a nonempty sequence of nonbreak characters. A break is a sequence of one or more break characters. Thus, the input can be viewed as a sequence of words separated by breaks, with possibly leading and trailing breaks, and ending with ET.

The program’s output should be the same sequence of words as in the input, with the exception that an oversize word (i.e., a word containing more than MAXPOS characters, where MAXPOS is a positive integer) should cause an error exit from the program (i.e., a variable, Alarm, should have the value TRUE). Up to the point of an error, the program’s output should have the following properties:

  • A new line should start only between words and at the beginning of the output text, if any.
  • A break in the input is reduced to a single break character in the output.
  • As many words as possible should be placed on each line (i.e., between successive NL characters).
  • No line may contain more than MAXPOS characters (words and BLs).

CSCE 431 Requirements

over specification
Over-specification

The program’s input is a stream of characters whoseend is signaled with a special end-of-text character, ET. There is exactly one ET character in each input stream. Characters are classified as:

  • break characters—BL (blank) and NL (new line);
  • nonbreak characters—all others except ET;
  • the end-of-text indicator–ET.

A word is a nonempty sequence of nonbreak characters. A break is a sequence of one or more break characters. Thus, the input can be viewed as a sequence of words separated by breaks, with possibly leading and trailing breaks, and ending with ET.

The program’s output should be the same sequence of words as in the input, with the exception that an oversize word (i.e., a word containing more than MAXPOS characters, where MAXPOS is a positive integer) should cause an error exit from the program (i.e., a variable, Alarm, should have the value TRUE). Up to the point of an error, the program’s output should have the following properties:

  • A new line should start only between words and at the beginning of the output text, if any.
  • A break in the input is reduced to a single break character in the output.
  • As many words as possible should be placed on each line (i.e., between successive NL characters).
  • No line may contain more than MAXPOS characters (words and BLs).

CSCE 431 Requirements

ambiguity
Ambiguity

The program’s input is a stream of characters whose end is signaled with a special end-of-text character, ET. There is exactly one ET character in each input stream. Characters are classified as:

  • break characters—BL (blank) and NL (new line);
  • nonbreak characters—all others except ET;
  • the end-of-text indicator–ET.

A word is a nonempty sequence of nonbreak characters. A break is a sequence of one or more break characters. Thus, the input can be viewed as a sequence of words separated by breaks, with possibly leading and trailing breaks, and ending with ET.

The program’s output should be the same sequence of words as in the input, with the exception that an oversize word (i.e., a word containing more than MAXPOS characters, where MAXPOS is a positive integer) should cause an error exit from the program (i.e., a variable, Alarm, should have the value TRUE). Up to the point of an error, the program’s output should have the following properties:

  • A new line should start only between words and at the beginning of the output text, if any.
  • A break in the input is reduced to a single break character in the output.
  • As many words as possible should be placed on each line (i.e., between successive NL characters).
  • No linemay contain more than MAXPOS characters (words and BLs).

CSCE 431 Requirements

forward references implicit
Forward References (implicit)

The program’s input is a stream of characters whose end is signaled with a special end-of-text character, ET. There is exactly one ET character in each input stream. Characters are classified as:

  • break characters—BL (blank) and NL (new line);
  • nonbreak characters—all others except ET;
  • the end-of-text indicator–ET.

A word is a nonempty sequence of nonbreak characters. A break is a sequence of one or more break characters. Thus, the input can be viewed as a sequence of words separated by breaks, with possibly leading and trailing breaks, and ending with ET.

The program’s output should be the same sequence of words as in the input, with the exception that an oversize word (i.e., a word containing more than MAXPOS characters, where MAXPOS is a positive integer) should cause an error exit from the program (i.e., a variable, Alarm, should have the value TRUE). Up to the point of an error, the program’s output should have the following properties:

  • A new line should start only between words and at the beginning of the output text, if any.
  • A break in the input is reduced to a single break character in the output.
  • As many words as possible should be placed on each line (i.e., between successive NL characters).
  • No line may contain more than MAXPOS characters (words and BLs).

CSCE 431 Requirements

improved w o quotes
Improved (w/o Quotes)

Given are a non-negative integer MAXPOS and a character set including two “break characters” blankand new_line. The program shall accept as input a finite sequence of characters and produce as output a sequence of characters satisfying the following conditions:

  • It only differs from the input by having a single break character wherever the input has one or more break characters.
  • Any MAXPOS+1 consecutive characters include a new_line.
  • The number of new_line characters is minimal.
  • If (and only if) an input sequence contains a group of MAXPOS+1 consecutive non-break characters, there exists no such output. In this case, the program shall produce the output associated with the initial part of the sequence up to and including the MAXPOS-th character of the first such group, and report the error.

Spec from Meyer

CSCE 431 Requirements

verifiable requirements
Verifiable Requirements
  • Non-verifiable:
    • The system shall work satisfactorily
    • The interface shall be user-friendly
    • The system shall respond in real time
  • Verifiable:
    • The output shall in all cases be produced ≤30s after the corresponding input event. It shall be produced in ≤10s for 80% of input events.
    • Professional train drivers will reach level 1 of proficiency (defined in requirements) in two days of training.
  • Favor precise, falsifiable language over pleasant generalities!

CSCE 431 Requirements

complete requirements
Complete Requirements
  • Complete w.r.t. what?
  • Definition from IEEE standard:

An SRS (Software Requirements Specification) is complete if, and only if, it includes the following elements:

    • All significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces. In particular any external requirements imposed by a system specification should be acknowledged and treated.
    • Definition of the responses of the software to all realizable classes of input data in all realizable classes of situations. Note that it is important to specify the responses to both valid and invalid input values.
    • Full labels and references to all figures, tables, and diagrams in the SRS and definition of all terms and units of measure.

CSCE 431 Requirements

complete requirements1
Complete Requirements
  • Completeness cannot be completely defined
  • Cross-checking mutators vs. accessors (so that all effects defined) at least useful – “sufficient complexity”
    • E.g. consider each accessor for each possible use of mutators
  • “Think negatively” – how can I break it

CSCE 431 Requirements

outline4
Outline
  • Motivation
  • Ethics
  • Overview of Requirements Task
  • Recognizing Good Requirements
  • Standards and Methods
  • Requirements Elicitation
  • About UML

CSCE 431 Requirements

why se standards
Why SE Standards?
  • SE standards:
    • Define common practice
    • Guide new engineers
    • Make software engineering processes comparable
    • Enable certification

CSCE 431 Requirements

ieee 830 1998
IEEE 830-1998
  • IEEE Recommended Practice for Software Requirements Specifications
  • Approved 25 June 1998 (revision of earlier standard)
  • Descriptions of the content and the qualities of a good software requirements specification (SRS).
  • Goal: “The SRS should be correct, unambiguous, complete, consistent, ranked for importance and/or stability, verifiable, modifiable, traceable.”

CSCE 431 Requirements

ieee standard definitions
IEEE Standard: Definitions

Contract A legally binding document agreed upon by the customer and supplier. This includes the technical and organizational requirements, cost, and schedule for a product. A contract may also contain informal but useful information such as the commitments or expectations of the parties involved.

Customer The person, or persons, who pay for the product and usually (but not necessarily) decide the requirements. In the context of this recommended practice the customer and the supplier may be members of the same organization.

Supplier The person, or persons, who produce a product for a customer. In the context of this recommended practice, the customer and the supplier may be members of the same organization.

User The person, or persons, who operate or interact directly with the product. The user(s) and the customer(s) are often not the same person(s).

CSCE 431 Requirements

issues addressed
Issues Addressed
  • Basic issues to be addressed by an SRS:
  • Functionality
    • What is the software supposed to do?
  • External interfaces
    • How does the software interact with people, the system’s hardware, other hardware, and other software?
  • Performance
    • What is the speed, availability, response time, recovery time of various software functions,…?
  • Attributes
    • What are the portability, correctness, maintainability, security,... considerations?
  • Design constraints imposed on an implementation
    • Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s),…?
  • The SRS writer(s) should avoid placing either design or project requirements in the SRS

CSCE 431 Requirements

ieee standard srs s recommended structure
IEEE Standard: SRS’s Recommended Structure

1. Introduction

1.1. Purpose

1.2. Scope

1.3. Definitions, acronyms, and abbreviations Glossary

1.4. References

1.5. Overview

2. Overall description

2.1. Product perspective

2.2. Product functions

2.3. User characteristics

2.4. Constraints

2.5. Assumptions and dependencies

3. Specific requirements

Appendices

Index

It makes sense to use the recommended structure

CSCE 431 Requirements

example section scope
Example Section: Scope
  • Identify software product to be produced by name (e.g., Host DBMS, Report Generator, etc.)
  • Explain what the product will and will not do
  • Describe application of the software: goals and benefits
  • Establish relation with higher-level system requirements if any

CSCE 431 Requirements

example section product perspective
Example Section: Product Perspective
  • Describe relation with other products if any
  • Examples:
    • System interfaces
    • User interfaces
    • Hardware interfaces
    • Software interfaces
    • Communications interfaces
    • Memory
    • Operations
    • Site adaptation requirements

CSCE 431 Requirements

example section constraints
Example Section: Constraints
  • Describe any properties that will limit the developers’ options
  • Examples:
    • Regulatory policies
    • Hardware limitations (e.g., signal timing requirements)
    • Interfaces to other applications
    • Parallel operation
    • Audit functions
    • Control functions
    • Higher-order language requirements
    • Reliability requirements
    • Criticality of the application
    • Safety and security considerations

CSCE 431 Requirements

specific requirements section 3
Specific Requirements (Section 3)
  • This section brings requirements to a level of detail usable by designers and testers
  • Examples:
    • Details on external interfaces
    • Precise specification of each function
    • Responses to abnormal situations
    • Detailed performance requirements
    • Database requirements
    • Design constraints
    • Specific attributes such as reliability, availability, security, portability

CSCE 431 Requirements

possible section 3 structure
Possible Section 3 Structure

3. Specific requirements

3.1 External interfaces

3.1.1 User interfaces

3.1.2 Hardware interfaces

3.1.3 Software interfaces

3.1.4 Communication interfaces

3.2 Functional requirements…

3.3 Performance requirements…

3.4 Design constraints…

3.5 Quality requirements…

3.6 Other requirements

CSCE 431 Requirements

requirements and agile methods
Requirements and Agile Methods
  • Under XP (Extreme Programming)
    • Requirements are taken into account as defined at the particular time considered
    • Requirements are largely embedded in test cases
  • Benefits
    • Test plan will be directly available
    • Customer involvement
  • Risks
    • Change may be difficult (refactoring)
    • Structure may not be right
    • Tests only cover the foreseen cases
  • Possibly useful advise
    • Retain the best agile practices, in particular frequent iterations, customer involvement, centrality of code and testing
    • Disregard those that contradict proven SE principles

CSCE 431 Requirements

recipes for good requirements
Recipes for Good Requirements
  • Managerial aspects:
    • Involve all stakeholders
    • Establish procedures for controlled change
    • Establish mechanisms for traceability
  • Treat requirements document as one of the major assets of the project; focus on clarity, precision, completeness
  • Technical aspects:
    • How to be precise? Formal methods?

CSCE 431 Requirements

using natural language for requirements
Using Natural Language for Requirements
  • Keys are:
    • Structure
    • Precision (including precise definition of all terms)
    • Consistency
    • Minimizing forward and outward references
    • Clarity
    • Conciseness

CSCE 431 Requirements

advice on natural language
Advice on Natural Language
  • Apply the general rules of “good writing” (e.g. Strunk & White)
  • Use active form (Counter-example: “the message will be transmitted. . . ”). This forces you to state who does what
  • Use prescriptive language (“shall… ”)
  • Separate domain properties and requirements
  • For delicate or complex issues, use complementary formalisms:
    • Illustrations (with precise semantics)
    • Formal descriptions, with explanations in English
  • Even for natural language specs, a mathematical detour may be useful

CSCE 431 Requirements

advice on natural language1
Advice on Natural Language
  • When using numbers, identify the units
  • When introducing a list, describe all the elements
  • Use illustrations to clarify
  • Define all project terms in a glossary
  • Consider placing individual requirements in a separate paragraph, individually numbered
  • Define generic verbs (“transmitted”, “sent”, “downloaded”, “processed”. . . ) precisely

M. Mannionand B. Keepence, SMART Requirements, ACM SIGSOFT SENotes, vol. 20, no. 2, pp. 42-47, April 1995.

CSCE 431 Requirements

outline5
Outline
  • Motivation
  • Ethics
  • Overview of Requirements Task
  • Recognizing Good Requirements
  • Standards and Methods
  • Requirements Elicitation
  • About UML

CSCE 431 Requirements

techniques for requirements elicitation
Techniques for Requirements Elicitation
  • Questionnaires: Asking the end user a list of pre-selected questions
  • Task Analysis: Observing end users in their operational environment
  • Scenarios: Describe the use of the system as a series of interactions between a specific end user and the system
  • Use Cases: Abstractions that describe a class of scenarios

CSCE 431 Requirements

scenario
Scenario
  • A description of an event or series of actions and events
  • In SE: a description of a use/uses of a system
  • The description is written from an end user’s point of view
  • A scenario can include text, video, pictures and story boards. It usually also contains details about the work place, social situations and resource constraints
  • A narrative description of what people do and experience as they try to make use of computer systems and applications [M. Carroll, Scenario-Based Design, Wiley, 1995]
  • A concrete, focused, informal description of a single feature of the system used by a single actor
  • Goal is to increase understanding of the system

Bruegge, Dutoit: Object-Oriented Software Engineering: Using UML, Java, and Patterns

CSCE 431 Requirements

rationale for scenarios
Rationale for Scenarios
  • For many, it is easier to relate to real-life examples than to abstract descriptions of possible behaviors
  • People can understand and critique a scenario of a planned interaction with a system

CSCE 431 Requirements

finding scenarios
Finding Scenarios
  • Do not expect the client to be verbose if the system does not exist
    • Client understands the application domain (problem domain), not the solution domain
  • Do not wait for information even if the system exists
    • “What is obvious does not need to be said”
  • Dialog
    • Developer helps the client to formulate the requirements
    • Client helps the developer to understand the requirements
    • The requirements evolve while the scenarios are being developed

Bruegge, Dutoit: Object-Oriented Software Engineering: Using UML, Java, and Patterns

CSCE 431 Requirements

scenario example
Scenario Example

Bob, driving down Main Street in his patrol car, notices smoke coming out of a warehouse. His partner, Alice, reports the emergency from their car.

Alice enters the address of the building into her wearable computer, a brief description of its location (i.e., NW corner), and an emergency level. She confirms her input and waits for an acknowledgment.

John, the dispatcher, is alerted to the emergency by a beep of his workstation. He reviews the information submitted by Alice and acknowledges the report. He allocates a fire unit and sends the estimated arrival time (ETA) to Alice. Alice receives the acknowledgment and the ETA.

  • Observations
    • Concrete
    • Describes a single instance, not all possible situations
    • Mentions participants

CSCE 431 Requirements

heuristics
Heuristics
  • Useful questions:
    • What are the primary tasks that the system needs to perform?
    • What data will an actor create, store, change, remove or add in the system?
    • What external changes does the system need to know about?
    • What changes or events will an actor of the system need to be informed about?
  • Instead of only relying on questions and questionnaires, perform task observation if the system already exists (interface engineering or reengineering)
  • Speak with end users, not just to the client
  • Expect resistance

Bruegge, Dutoit: Object-Oriented Software Engineering: Using UML, Java, and Patterns

CSCE 431 Requirements

use cases
Use Cases
  • Ause case defines a goal-oriented set of interactions between external actors and the system under consideration.
  • Actors are parties outside the system that interact with the system
    • An actor may be a class of users, roles users can play, or other systems.
  • Ause case is initiated by a user with a particular goal in mind, and completes successfully when that goal is satisfied.
  • Includes possible variants of a sequence interactions satisfying the goal or variants that lead to failure

CSCE 431 Requirements

use cases1
Use Cases
  • The system treated as a “black box” (== the interactions with system, including system responses, are as perceived from outside the system)
  • Use cases capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with system internals
  • Acomplete set of use cases specifies all the different ways to use the system, and therefore defines all behavior required of the system, bounding the scope of the system.
  • Use case steps are written in an easy-to-understand structured narrative using the vocabulary of the domain
    • With some help from graphical notations, such as UML use case and sequence diagrams

CSCE 431 Requirements

use cases and scenarios
Use Cases and Scenarios
  • Use cases (often) defined based on scenarios
  • Use cases vs. scenarios:
    • Use case encapsulates a set of scenarios
    • Each scenario is a single thread through a use case

CSCE 431 Requirements

outline6
Outline
  • Motivation
  • Ethics
  • Overview of Requirements Task
  • Recognizing Good Requirements
  • Standards and Methods
  • Requirements Elicitation
  • About UML

CSCE 431 Requirements

what is uml
What is UML?
  • UML == Unified Modeling Language
  • Nonproprietary standard for modeling software systems, OMG
  • Convergence of notations used in object-oriented methods
    • OMT (Object Modeling Technique, James Rumbaugh and colleagues)
    • Booch (Grady Booch)
    • OOSE (Ivar Jacobson)
  • Current Version: UML 2.3 (May 2010)
  • Information at the OMG portal http://www.uml.org
  • Commercial tools:
    • Rational (IBM), Together (Borland), Visual Architect (business processes, BCD)
  • Open Source tools:
    • ArgoUML, BOUML, Dia,…

CSCE 431 Requirements

uml diagrams
UML Diagrams

CSCE 431 Requirements

uml diagrams1
UML Diagrams
  • Use case diagrams
    • Describe the functional behavior of the system as seen by the user
  • Class diagrams
    • Describe the static structure of the system: Objects, attributes, associations
  • Sequence diagrams
    • Describe the dynamic behavior between objects of the system
  • Statechart diagrams
    • Describe the dynamic behavior of an individual object
  • Activity diagrams
    • Describe the dynamic behavior of a system, in particular the workflow

CSCE 431 Requirements

uml conventions
UML Conventions
  • All UML Diagrams are graphs of nodes and edges
  • Nodes are entities and drawn as rectangles or ovals
    • Rectangles denote classes or instances
    • Ovals denote functions
  • Names of Classes are not underlined
    • SimpleTimer
    • Employee
  • Names of Instances are underlined
    • aTimer:SimpleTimer
    • JohnSmith:Employee
  • An edge between two nodes denotes a relationship between the corresponding entities

CSCE 431 Requirements

use case diagrams
Use Case Diagrams
  • Used during requirements elicitation and analysis to represent behavior visible from outside the system
  • An actor represents a role (a specific kind of a user of the system)
  • A use case represents a class of functionality provided by the system
  • Use case model is the set of all use cases that completely describe the system functionality

CSCE 431 Requirements

actor
Actor
  • A model for an external entity that interacts with the system
    • End user, administrator
    • External system
    • Physical environment (weather)
  • Has a unique name and an optional description
  • Examples:
    • Student: a person that studies
    • Teaching assistant: member of teaching staff who supports the instructor
    • Random number generator

CSCE 431 Requirements

use case
Use Case
  • Class of functionality
  • Focus of description of a use case is the event flow between actors and system
  • Not just UML use case diagrams, narrative should describe in detail:
    • Participating actors
    • Entry condition
    • Flow of events
    • Exit condition
    • Exceptions
    • Nonfunctional requirements

CSCE 431 Requirements

use case model
Use Case Model

Bruegge, Dutoit: Object-Oriented Software Engineering: Using UML, Java, and Patterns

CSCE 431 Requirements

related use cases
Related Use Cases
  • Extend Relationship
    • To represent seldom invoked use cases or exceptional functionality
      • «extend» relationships model exceptional or seldom invoked cases
      • The exceptional event flows are factored out of the main event flow for clarity
      • The direction of an «extend» relationship is to the use case being extended
      • Use cases representing exceptional flows can extend more than one use case.
  • Include Relationship
    • To represent functional behavior common to more than one use case
    • «include» behavior is factored out for reuse, not because it is an exception
    • The direction of an «include»relationship is to the use case being used

CSCE 431 Requirements

example extend include
Example: extend, include

Bruegge, Dutoit: Object-Oriented Software Engineering: Using UML, Java, and Patterns

CSCE 431 Requirements

description example
Description Example

1. Name: DoHomework

2. Participating actor:

Student

3. Entry condition:

1. Student ready to download exercise sheet

4. Exit condition:

1. Student delivered solution

5. Flow of events:

5.1. Student downloads

the exercise sheet

5.2. Student reads

through the assignments

5.3. Student processes the

assignments and types the

solution in his Computer.

5.4. Student prints out

the solution

5.5. Student delivers the

solution through the

submission system

6. Special requirements: None

CSCE 431 Requirements

advice
Advice
  • A good use case must:
    • Describe a business task
    • Not be implementation-specific
    • Provide appropriate level of detail
    • Be short enough to be implemented by one developer in one release

CSCE 431 Requirements

value of use cases debated
Value of Use Cases Debated
  • According to Meyer:

Use cases are a minor tool for requirement elicitation but not really a requirement technique. They cannot define the requirements:

      • Not abstract enough
      • Too specific
      • Describe current processes
      • Do not support evolution

“Use cases are to requirements what tests are to software specification and design”

  • Cannot capture all requirements of a system

CSCE 431 Requirements

summary of requirements
Summary of Requirements
  • Goal: SRS that describe the problem, not solution
  • Variety of sources and means for eliciting requirements
    • Use what makes most sense in the situation
  • Variety of definition and specification techniques
    • Use what makes most sense in the situation
  • Requirements should be validated (that they meet customer expectations)
  • Specifications should be verified (that they satisfy requirements)

CSCE 431 Requirements