CS 501: Software Engineering Fall 2000 Lecture 6 (a) Requirements Analysis (continued) (b) Requirements Specification.

Slides:



Advertisements
Similar presentations
CIS 376 Bruce R. Maxim UM-Dearborn
Advertisements

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System modeling 2.
1 SWE 513: Software Engineering Requirements II. 2 Details in Requirements Requirements must be specific Examples -- university admissions system Requests.
29 January Requirement Specification Assignment 1, Software Engineering, VT08 Sabesan Information Technology Uppsala University.
1 CS 501 Spring 2008 CS 501: Software Engineering Lecture 10 Requirements 3.
1 / 26 CS 425/625 Software Engineering Software Requirements Based on Chapter 5 of the textbook [Somm00] Ian Sommerville, Software Engineering, 6 th Ed.,
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 8 Requirements I.
1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 8 Requirements II.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
7M701 1 Software Engineering Software Requirements Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 5
CS 425/625 Software Engineering Software Requirements
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements.
CS 5150 Software Engineering
Software Requirements
1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 7 Requirements I.
1 CS 502: Computing Methods for Digital Libraries Lecture 13 Descriptive Metadata I: cataloguing, classification, authority files.
1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 7 Requirements I.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 9 Requirements 3.
CS 5150 Software Engineering
CS 501: Software Engineering Fall 2000
CS 501: Software Engineering Fall 2000 Lecture 5 (a) Documentation (b) Requirements Analysis.
CS 501: Software Engineering
Software engineering Olli Alm Lecture 2: requirements, modelling & representation.
1 CS 501 Spring 2008 CS 501: Software Engineering Lecture 7 Requirements I.
CS CS 5150 Software Engineering Lecture 10 Requirements 3.
CS CS 5150 Software Engineering Lecture 10 Requirements 3.
1 CS 501 Spring 2006 CS 501: Software Engineering Lecture 9 Requirements 3.
7M822 Software Requirements Introduction 7 September 2010.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements 2.
Software Requirements
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Requirements engineering l The process of establishing the services that the.
1 CS 430: Information Discovery Lecture 5 Descriptive Metadata 1 Library Catalogs MARC.
CS 4310: Software Engineering Lecture 3 Requirements and Design.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
©Ian Sommerville Software Engineering Slide 1 Software Requirements l Definition: Description and Specifications of a system l Topics covered: Functional.
Requirements Elicitation. Who are the stakeholders in determining system requirements, and how does their viewpoint influence the process? How are non-technical.
CS CS 5150 Software Engineering Lecture 10 Requirements 3.
1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 9 Techniques for Requirements Definition and Specification I.
1 CS 430: Information Discovery Lecture 6 Descriptive Metadata 2 Library Catalogs Dublin Core.
CS 4310: Software Engineering Lecture 4 System Modeling The Analysis Stage.
Requirements Reference: Chapters 5, 6, & 8. CMSC 345, Fall Objectives To introduce the concepts of user and system requirements To explain functional.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Slide 1 Analysis Workflow l The primary activities of the Analysis workflow are.
1 15 quality goals for requirements  Justified  Correct  Complete  Consistent  Unambiguous  Feasible  Abstract  Traceable  Delimited  Interfaced.
Lecture 2 Developing Requirements
1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 8 Requirements Analysis and Specification.
L To identify the services that the customer requires from a system and the constraints under which it operates and is developed.
Slide 1 CS 310 Ch 6: Software Requirements Requirements engineering: establishing the services that the customer requires from a system and the constraints.
Systems Development Life Cycle
Week 3: Requirement Analysis & specification
1 CS 430: Information Discovery Lecture 6 Descriptive Metadata 2 Library Catalogs.
SWE 513: Software Engineering
CS CS 5150 Software Engineering Lecture 8 Requirements 1.
1 CS 501 Spring 2004 CS 501: Software Engineering Lecture 9 Requirements 3.
CS CS 5150 Software Engineering Lecture 8 Requirements 1.
CS 501: Software Engineering Fall 1999 Lecture 4 (a) Documentation (b) Requirements Analysis.
Your Interactive Guide to the Digital World Discovering Computers 2012 Chapter 12 Exploring Information System Development.
CS 501: Software Engineering Fall 199 Lecture 1 a) Administration b) Introduction to Software Engineering.
CS 5150 Software Engineering Lecture 9 Requirements 3.
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 11 Requirements III.
CS 501: Software Engineering Fall 1999 Lecture 5 (a) Requirements Analysis (continued) (b) Requirements Specification.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements (utvalgte foiler fra Kap 6 og 7 i Sommerville)
1 CS 501 Spring 2004 CS 501: Software Engineering Lecture 7 Requirements I.
Theory, Tools, History: A Brief Introduction August 17, 2016.
Software Engineering Lecture 4 System Modeling The Analysis Stage.
Classifications of Software Requirements
Lecture 2 Developing Requirements
CS 501: Software Engineering Fall 1999
Requirements Analysis
Subject Name: SOFTWARE ENGINEERING Subject Code:10IS51
Presentation transcript:

CS 501: Software Engineering Fall 2000 Lecture 6 (a) Requirements Analysis (continued) (b) Requirements Specification

Administration Introduction of André Allavena Due date for Assignment 1 is Wednesday 5 p.m. Teaching Assistant assignment to projects will be made on Thursday

Wireless Laptops Read As part of Assignment 1, each project should: => list the people who will be issued with laptops, up to 3 people per project + one alternate => list people who will be issued with wireless cards, up to 2 per project Distribution times and places are: => Thursday, September 14th, 2:30 - 4:00 pm, Upson 5126 => Friday, September 15th, 10: :30 am, Upson 5130

The Requirements Process Feasibility Study Requirements Analysis Requirements Definition Requirements Specification Feasibility Report System Models Definition of Requirements Specification of Requirements Document

Requirements Analysis Methods for data modeling and design Data flow diagrams Entity-relation diagrams Data dictionaries Object models Many of these methods blur the distinction between analysis and design.

Entity-Relation Model A Design Methodology for Relational Databases A database of entities and relations Tools for displaying and manipulating entity- relation diagrams Tools for manipulating the database (e.g., as input to database design) Warning: There is much confusion about definitions and notation

Entity-Relation Diagram An entity A relation between entities An entity or relation attribute An inheritance relation

Example: CS 501 Project Student CS501 Student Major Project 5 to 7 1 Member of Person Client 1 Tech contact 0:n

Example: MARC Catalog Record Caroline R. Arms, editor, Campus strategies for libraries and electronic information. Bedford, MA: Digital Press, 1990.

MARC Format for Monographs (Books) r Campus strategies for libraries and electronic information 260 {Bedford, Mass.} : Digital Press, c Academic libraries--United States--Automation. 650 Libraries and electronic publishing--United States. 700 Arms, Caroline R. (Caroline Ruth)

Entity-Relation Diagram for MARC Book Short title Catalog record Describes Control numb Subject heading Is about Creator Editor of Author of 1:n 1 0:n

Data Dictionaries A data dictionary is a list of names used by the system Brief definition (e.g., what is "date") What is it (e.g., number, relation) Where is it used (e.g., source, used by, etc.) May be combined with a glossary As the system is implemented, the data dictionary in the requirements is input to the system data dictionary, which is a formal part of the system specification.

A Note on Object Models This course teaches object models as a tool for design. Some people recommend object models for requirements analysis, but it is difficult to use them without constraining the system design.

Non-Functional Requirements Product requirements performance, reliability, portability, etc... Organizational requirements delivery, training, standards, etc... External requirements legal, interoperability, etc...

Examples of Non-Functional Requirements Privacy (Mercury digital library) Functional requirement: Usage data for management of system Non-functional requirement: Usage data must not identify individuals Minimizing records (NeXT) Functional requirement: Retain all required records Non-functional requirement: Discard all other records

Unspoken Requirements Example: Resistance to change at XXX

Requirements Specification What is the purpose of the Requirements Specification?

Requirements Specification: Purpose 1. It describes the requirements to the stakeholders Expressed in the terms that the stakeholders understand Comprehensible from many viewpoints Reviewed by stakeholders so that they understand implications Must be clear about assumptions (things left out)

Requirements Specification: Purpose 2. It describes the requirements to the implementers As precise and specific as possible Expressed in terms that they understand Comprehensible to new team members

Requirements Specification: Purpose 3. It records the requirements for the future An essential part of system evolution 4. If may be a contractual document See you in court!

Requirements Specification: Approaches Natural language Structured natural language Design description language Requirements specification language Graphical notation Formal specification See Sommerville, Chapter 7.