CS 501: Software Engineering. Lecture 8 Requirements I . Administration. Project Presentations. Requirements. Requirements Analysis. System design. Design. Program design. Implementation. Coding. Unit & Integration Testing. System Testing. Acceptance Testing.
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.
Unit & Integration Testing
Operation & Maintenance
Unit & Integration Testing
Operation & Maintenance
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.
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.
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!
• If the requirements definition is wrong, the system will be
• With complex systems, understanding of requirements
always continues to improve.
• The requirements definition must evolve.
• Its documentation must be kept current (but clearly
• 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
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?).
FOR NDLP PRODUCTION AND DELIVERY OF AMERICAN MEMORY
(for repository test)
Current Storage Structure
(in Unix files, by aggregate)
Object Administration System
American Memory User Interface
(retrieval, navigation, & display)
AM user interface plus
Other User Interfaces
(e.g. RLG, OCLC, DLF partners)
ILS OPAC Interface
Privacy (Mercury digital library)
Usage data for management of system
Usage data must not identify individuals
Minimizing records (NeXT)
Retain all required records
Discard all other records
performance, reliability, portability, etc...
delivery, training, standards, etc...
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
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.
1. Identify the stakeholders:
• Who is affected by this system?
etc., etc., etc.,
Example: Andrew project (Carnegie Mellon and IBM?)
• Who can disrupt this project?
2. Understand the requirements in depth:
• Domain understanding
Examples: Philips light bulbs
• Understanding of the real requirements of all stakeholders
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.
Example: University Admissions System
• University administration
Financial aid office
Special offices (e.g., athletics, development)
• Computing staff
Software development and maintenance
• Academic departments
3. Organize the requirements:
• Classification into coherent clusters
(e.g., legal requirements)
• Recognize and resolve conflicts
(e.g., functionality v. cost v. timeliness)
Example: Dartmouth general ledger system