Upload
joan-hicks
View
230
Download
0
Tags:
Embed Size (px)
Citation preview
Requirements Documentation
CSCI 5801: Software Engineering
Requirement Documentation
Requirement Documentation
• Unambiguous– Developers and clients have same understanding of
what system must do
• Understandable– Simple enough for clients to understand– Detailed enough for you to create system based on it
Definition vs. Specification
• Requirements definition– Stated from the viewpoint of somebody outside
the system (external viewpoint)– The system is a black box with some interface– The emphasis is on the role of the system
• Example: “The sprinkler never runs on rainy days”
Definition vs. Specification
• Requirements specification– Stated from the viewpoint of somebody inside the
system– The environment is accessed via inputs & outputs– The emphasis is on how the system works
• Example: “The controller will not engage the water pump any time the ambient water sensor is triggered.”
Definition vs. Specification
• Requirements documentation may contain both– Definition: best for customers– Specification best for developers
• Understand difference• If use both, make sure they agree
Scenarios
• Real-life examples of how system used– Single type of action taken by user and how system
responds (like user story in XP)– “Atomic” form of functional requirements
• Should include:– A description of the starting situation– A description of the normal flow of events– A description of what can go wrong– A description of the state when the scenario finishes
Common Scenario Components
• A unique name and simple one-sentence description• An initial assumption
– Preconditions that must be true at start of scenario
• A description of the normal steps – What user does and what system does in response
• A list of exceptions– What could go wrong, and what system must do
• System state upon completion of the scenario• Other simultaneous activities that could affect system• Any nonfunctional requirements
Example Scenario
“Fred wants to add CSIS 1590. He looks up the course on the system to get available sections. He likes the one at MWF 10 and selects it. His ID is added to the course roster”.
• What does student have to do before this?• How can student look up sections?• What if no open sections?• What is student does not like any of the open sections?• What can the student do next?• How does this relate to what other students are doing?
Example Scenario
Add ScenarioDescription: • A student adds a course by entering a course number
and selecting a section.Initial Assumption: • Student has logged in and navigated to ADD screen,
and has selected a course to add.
Example Scenario
Normal Steps:• System populates dropdown list of courses.• Student selects a course from the list.• A drop down with open sections (including their times) is
populated.• The student selects one and presses ADD.• The student is added to the course roster.• An acknowledgement of the add is displayed.• The student may add more courses, or exit to the main
menu.
Example Scenario
Exceptions: • All sections of the selected course may be closed, in which
case a message is popped up instead of the drop down being populated.
• The student may not like any of the open sections, in which case they can either enter another course or press CANCEL to return to the main menu.
• The course may be closed before the student presses ADD, due to other students adding, in which case a message is displayed and the list of open sections displayed again.
Example Scenario
System State upon Completion: • The student ID is added to the roster of the section
chosen. If that was the last remaining seat, the section is now closed.
Simultaneous activities:• Up to 500 other students may be adding and
dropping courses. This might result in courses closing while the student is in the process of adding this one. It might also affect response time.
Example Scenario
Nonfunctional Requirements: • On average a student who has registered for one
semester previously should make no more than 3 mistakes during an entire session and should be able to add all of their courses within 15 minutes.
• For requests for open sections, the system response time should be less than 2 seconds in 90% of cases under normal load.
Unified Modeling Language (UML)
Unified Modeling Language (UML)
• Graphical representations for design/analysis– How we tend to do design
• Common design specification language– Experienced developer should be able to immediately
understand system from diagram– Simple enough for customer to understand– Well-defined enough to allow developers to create system
Unified Modeling Language (UML)
• Based on earlier graphical representations– Entity Relationship diagrams (from database design)– Finite state machines– Data flow diagrams
• Controlled by OMG (Object Management Group) consortium– Latest version: UML 2
• UML 2 has 13 diagram types– Often loose semantics– Some types used more than others
Use Case Diagrams
• Define major roles of entities in system– Usually in terms of user activities– Actors that interact with system for that activity
Registration Use Cases
Use Case Refinement
• Can show overall use case as sequence of other use cases
Use Case Refinement
• Can extend general use case to more specific ones
Sequence Diagrams
• Define role of each object in overall use case– Each object has “lifeline”– Describe information passed/returned– May show options for multiple scenarios in same use case– Also used at design to show information flow inside system
Sequence Diagram
Mathematical Specifications
• The deceleration of the train shall be computed as:– Dtrain = Dcontrol + Dgradient
where Dgradient is 9.81ms2 * compensated gradient/alpha and where the values of 9.81ms2 /alpha are known for different types of train.
Tabular Specification
Condition Action
Sugar level falling (r2 < r1) CompDose = 0
Sugar level stable (r2 = r1) CompDose = 0
Sugar level increasing and rate of increase decreasing ((r2-r1)<(r1-r0))
CompDose = 0
Sugar level increasing and rate of increase stable or increasing. ((r2-r1) ≥ (r1-r0))
CompDose = round ((r2-r1)/4) If rounded result = 0 then CompDose = MinimumDose
IEEE requirements standard
• Defines a generic structure for a requirements– Introduction.
• General background and purpose of system
– General description• Requirements described at customer level
– Specific requirements.• Requirements described at developer level
– Appendices.– Index.
IEEE Standard 830
1. Introduction1.1. Purpose1.2. Scope1.3. Definitions, acronyms and abbreviations1.4. References1.5. Overview
27
Based on feasibility study
Glossary of possibly ambiguous termsCRN, course number, advisor, etc.
Sources of requirements (interviews, recordings, forms, etc.)
IEEE Standard 8302. General description
2.1. Product perspective
2.2. Product functions
2.3. User characteristics
2.4. Constraints2.5. Assumptions and dependencies
28
Hardware and software system will run on
List of features system will have (written at customer level)
Description of users of system, including knowledge of domain and experience with computing
IEEE Standard 830
3. Specific requirements3.1. External interface
requirements3.1.1. User interfaces
3.1.2. Hardware interfaces3.1.3. Software interfaces3.1.4. Comm. interfaces
29
General description of user interfaces, including layouts common to all scenarios, and general UI functional requirements such as training time
Descriptions of hardware (such as sensors), legacy software, and networks the system must work with
IEEE Standard 830
3.2. Functional requirements3.2.1. User class 1
3.2.1.1. Functional req. 1.1
3.2.1.2. Functional req. 1.2
...3.2.2. User class 2
…
30
Detailed description of individual use cases in whatever form appropriate (scenarios, sequence diagrams, etc.)
IEEE Standard 8303.3. Performance requirements3.4. Design constraints3.5. Software system attributes3.6. Other requirements
SE, Requirements Engineering, Hans van Vliet, ©2007 31
General non-functional requirements not directly related to any specific scenario, such as overall performance, general reliability, sustainability, etc.