1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 1 Introduction to Software Engineering.
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 8 Requirements I.
-
date post
20-Dec-2015 -
Category
Documents
-
view
216 -
download
0
Transcript of 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 8 Requirements I.
3 CS 501 Spring 2003
Project Presentations
Requirements Analysis
System design
Unit & Integration Testing
System Testing
Operation & Maintenance
Program design
Coding
Acceptance Testing
Requirements
Design
Implementation
4 CS 501 Spring 2003
Feedback in the Waterfall Model
Requirements Analysis
System design
Unit & Integration Testing
System Testing
Operation & Maintenance
Program design
Coding
Acceptance Testing
5 CS 501 Spring 2003
Iterative Refinement
OutlineDescription
ConcurrentActivities
Requirements
Design
Implementation
InitialVersion
IntermediateVersions
FinalVersion
6 CS 501 Spring 2003
From an Old Exam Question
A computing system is likely to need some sort of database
(i) At what stage in the waterfall process, would the decision be made to use a relational database? Give the reasons for your answer.
(ii) At what stage in the waterfall process, would the decision be made to use an Oracle database? Give the reasons for your answer.
(iii) At what stage in the waterfall process would the database schema be specified? Give the reasons for your answer.
7 CS 501 Spring 2003
From an Old Exam Question (Answer)
A requirement is a statement of need as expressed by a client.
The client's requirements are that the system collects certain data, saves it, and carries out specified processes, e.g., displaying it, performing calculations, etc.
The decision of how to store and manipulate the data (e.g., using the relational database model) is usually not a requirement of the client. It comes later, as part of the design.
However. During the feasibility study it is important to know about relational databases, such as Oracle, and to study their capabilities.
8 CS 501 Spring 2003
Why are Requirements Important?
Causes of failed software projects (Standish Group study, 1994)
Incomplete requirements 13.1%Lack of user involvement 12.4%Lack of resources 10.6%Unrealistic expectations 9.9%Lack of executive support 9.3%Changing requirements & specifications 8.8%Lack of planning 8.1%System no longer needed 7.5%
The commonest mistake is to build the wrong system!
9 CS 501 Spring 2003
Evolution of Requirements
• If the requirements definition is wrong, the system will be a failure.
• With complex systems, understanding of requirements always continues to improve.
Therefore...
• The requirements definition must evolve.
• Its documentation must be kept current (but clearly identify versions).
10 CS 501 Spring 2003
Goals During the Requirements Phase
• Understand the requirements in detail (analysis)
• Describe the requirements in a manner that is clear to the client
• Ensure that the client understands the description of the requirements and their implications
• Describe the requirements in a manner that is clear to the people who will design and implement the system
11 CS 501 Spring 2003
The Requirements Process
FeasibilityStudy
RequirementsAnalysis
RequirementsDefinition
RequirementsSpecification
FeasibilityReport System
Models Definition ofRequirements
Specification ofRequirements
RequirementsDocument
12 CS 501 Spring 2003
Functional Requirements
Requirements about the functions that the system must perform
• Functionality
• Data
• Interfaces
• Users and human factors
13 CS 501 Spring 2003
Example of Functional Requirements
Library of Congress Repository
• Support for complex digital objects. (How many? What size?)
• Access management. (What users? What objects? Policies?)
• Identification. (Which identification system?)
• Information hiding. (Where are the interfaces?)
• Open protocols and formats. (How are these chosen?)
• Integration with existing systems (What legacy systems must be accommodated?).
14 CS 501 Spring 2003
Current Storage Structure (in Unix files, by aggregate)
Index Generation(including pre-processing)
American Memory User Interface(retrieval, navigation, & display)
Object Administration System
Repository
NDLP Workflow Tracking Support
Handle-server
NDLP collections already released
NDLP collections in conversion
Coolidge collection(for repository test)
Future NDLP collections
NOW FUTURE
ILS OPAC InterfaceOther User Interfaces (e.g. RLG, OCLC, DLF partners)
Other applicationsand materials
ILS
Handle assignment & registration Handle resolution
Supporting infrastructure
DRAFT OVERVIEW OF ITS SUPPORT FOR NDLP PRODUCTION AND DELIVERY OF AMERICAN MEMORY
AM user interface plus access management
for objects/collections
15 CS 501 Spring 2003
Non-Functional Requirements
Requirements about the context in which the system is built
• Documentation and training
• Resources
• Security
• Physical environment
• Quality assurance
16 CS 501 Spring 2003
Examples of Functional and 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
17 CS 501 Spring 2003
Non-Functional Requirements
Product requirements
performance, reliability, portability, etc...
Organizational requirements
delivery, training, standards, etc...
External requirements
legal, interoperability, etc...
Marketing and public relations
Example: In the NSDL, the NSF wanted a system that could be demonstrated by the end of 2002
18 CS 501 Spring 2003
Example of Non-Functional Requirements
Example: Library of Congress Repository
• Hardware and software systems (IBM/Unix)• Database systems (Oracle)• Programming languages (C and C++)
• Regulations covering government contracting
• Importance of developing a system that will be respected by other major libraries
19 CS 501 Spring 2003
Unspoken Requirements
Example:
• Resistance to change
• Departmental friction
• Management strengths and weaknesses
20 CS 501 Spring 2003
Requirements Analysis and Definition
High-level abstract description of requirements:
• Specifies external system behavior
• Comprehensible by customer, management and users
Should reflect accurately what the customer wants:
• Services that the system will provide
• Constraints under which it will operate
Described in a Requirements Document that can be understood by the client.
21 CS 501 Spring 2003
Requirements Analysis
1. Identify the stakeholders:
• Who is affected by this system?
ClientSenior managementProduction staffComputing staffCustomersetc., etc., etc.,
Example: Andrew project (Carnegie Mellon and IBM?)
• Who can disrupt this project?
22 CS 501 Spring 2003
Requirements Analysis
2. Understand the requirements in depth:
• Domain understanding
Examples: Philips light bulbs
• Understanding of the real requirements of all stakeholders
23 CS 501 Spring 2003
Interviews with Clients
Client interviews are the heart of requirements analysis and definition. Allow plenty of time.
Clients may have only a vague concept of requirements.
• Prepare before you meet with them
• Keep full notes
• If you don't understand, delve further
• Repeat what you hear
• Small group meetings are often most effective
Clients often confuse the current system with the underlying requirement.
24 CS 501 Spring 2003
Viewpoint Analysis
Example: University Admissions System
• Applicants
• University administrationAdmissions officeFinancial aid officeSpecial offices (e.g., athletics, development)
• Computing staffOperationsSoftware development and maintenance
• Academic departments