1. The Software Development Life Cycle: An Overview
Presented by
Maxwell Drew
and
Dan Kaiser
Southwest State University
Computer Science Program

2. Last Time Project Management Concepts
The Schwan’s Information Services Deliverables Guide
Project Management Techniques
Project Management in MSF
Project Management in RUP

3. Session 3: Agenda The Requirements Process Schwan’s Requirements Phase
MSF Requirements
RUP Requirements

4. Requirements
Requirement: a feature of the system or a description of something the system is capable of doing in order to fulfill the system’s purpose
Three kinds of requirements:
those that absolutely must be met
those that are highly desirable but not necessary
those that are possible but could be eliminated

5. Purpose of Requirements
To establish and maintain agreement with the customers and other stakeholders on what the system should do.
To provide system developers with a better understanding of the system requirements.
To define the boundaries of (delimit) the system.
To provide a basis for planning the technical contents of iterations.
To provide a basis for estimating cost and time to develop the system.
To define a user-interface for the system, focusing on the needs and goals of the users.

6. The Requirements Document
The requirements document is the official statement of what is required of the system developers
Should include both a definition and a specification of requirements
It is NOT a design document. As far as possible, it should set out WHAT the system should do rather than HOW it should do it

7. Requirements Requirements definition Requirements specification
A statement in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers
Requirements specification
A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor
Software specification
A detailed software description which can serve as a basis for a design or implementation. Written for developers

9. Functional vs. non-functional requirements
Functional: describes an interaction between the system and its environment
Examples:
System shall communicate with external system X.
What conditions must be met for a message to be sent
Non-functional: describes a restriction or constraint that limits our choices for constructing a solution
Examples:
Paychecks distributed no more than 4 hours after initial data are read.
System limits access to senior managers.

10. Types of requirements Physical environment Interfaces
Users and human factors
Functionality
Documentation
Data
Resources
Security
Quality assurance

11. Requirements Readers

12. Different Perspectives

13. Characteristics of requirements
Are they correct?
Are they consistent?
Are they complete?
Are they realistic?
Does each describe something the customer needs?
Are they verifiable?
Are they traceable?

14. Requirements Engineering Process
Feasibility study
Find out if the current user needs can be satisfied given the available technology and budget?
Requirements analysis
Find out what stakeholders require from the system
Requirements definition
Define the requirements in a form understandable to the customer
Requirements specification
Define the requirements in a detailed form for the designer

15. RE Process and its Deliverables

16. Discovering Requirements
Prototyping
Throw Away
Evolutionary
Both referred to as “rapid” prototyping
Use Cases
Will be discussed later

17. Expressing Requirements
Formal Methods
Axiomatic Definition
Specification Grammars
Mathematical Specifications
Recurrence Relations
Petri Nets
Formal methods have not been generally accepted by developers

18. Data Abstraction

19. Abstract Class Relationships

20. Transition Diagram (UML)

21. Entity Relationship Modeling

22. Example ERD

23. Object-Oriented Specifications
Each entity in the system is an object.
A method or operation is an action that can be performed directly by the object or can happen to the object.
Encapsulation: the methods form a protective boundary around an object.
Class hierarchies of objects encourage inheritance.
Polymorphism: same method for different objects, each with different behavior

24. Multiple Inheritance

25. Choosing a Specification Technique
Applicability
Implementability
Testability/simulation
Checkability
Maintainability
Modularity
Level of abstraction /expressibility
Soundness
Verifiability
Run-time safety
Tools maturity
Looseness
Learning curve
Technique maturity
Data modeling
Discipline

26. Requirements validation
Concerned with demonstrating that the requirements define the system that the customer really wants
Requirements error costs are high so validation is very important
Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error
Prototyping is an important technique of requirements validation

27. Requirements checking
Validity. Does the system provide the functions which best support the customer’s needs?
Consistency. Are there any requirements conflicts?
Completeness. Are all functions required by the customer included?
Realism. Can the requirements be implemented given available budget and technology

28. Validation Techniques

29. Questions?

30. Schwan’s Requirements Deliverables

32. Project Requirements Objective
The objective of the Project Requirements phase is to identify and document the business requirements for the project.  Business requirements define the vision for the completed project in terms that the customer and user can understand and should concentrate on the business processes rather than technical processes.

33. Business Specifications (210)
Objective The objective of the Business Specifications is to define the business rules and give a high level overview of the way the business processes are completed. The DBA’s may be involved at this stage. Required:Projects Optional:Support Deliverable to:Systems Development Customer (Optional)
Deliverables Business Event Model Retention: System Business Event Document Retention: System Functional Decomposition Diagram Retention: System Context Diagram Retention: System

34. Entity/Relationship Modeling (220)
Objective The objective of the Entity/Relationship Diagram is to define an Entity/ Relationship model and approve a Logical Data model with logical attributes (where database changes are needed). Cardinalities will be included to show the business flow and how the system potentially will work. DBA’s should be involved in this step. Required:Projects Optional:Support
Deliverable: Entity/Relationship Diagram Logical Data Model Deliverable to: Systems Development Customer (Optional) Responsibility:Business Systems Planning

35. Input/Output Requirements (230)
Objective The objective of the Input/Output Requirements is to develop the initial input and output requirements with the customer’s input and then review with the customer. Required: Projects Optional: Support
Deliverable: Input Requirements Output Requirements Deliverable to: Systems Development Customer Responsibility: Business Systems Planning SAP Tie: 2.4

36. Prototyping (240)
Objective The objective of the prototyping is to have the customer see the system and be able to give suggestions and approve the potential layout of the system. This is the beginning of reviewing potential third party packages if this is an option. Required: <None> Optional: Projects, Support
Deliverable: Customer Approval (Walkthrough form?) Deliverable to: Systems Development Customer Responsibility: Joint Responsibility SAP Tie: 2.3,2.5

37. Detailed Business Specifications (250)
Objective The objective of the Detailed Business Specifications is to detail the high level Business specifications’ using a method such as business use cases. Required: Projects Optional: Support
Deliverable: Technology Model Business Use Cases Business Detail Process Documentation Deliverable to: Systems Development Customer (Optional) Responsibility: Business Systems Planning SAP Tie: 2.4

38. Business Test Cases (260)
Objective The objective of the Business Test Cases is to have a written plan to confirm after creation that the system meets the business needs of the customer. This plan should include a list of functionality needed at the business level. Customers should help create the Business Test Cases. Required: ProjectsSupport Optional: <None>
Deliverable: Business Test Cases Deliverable to: Systems Development Customer (Optional) Responsibility: Business Systems Planning SAP Tie: 2.4

39. Project Approval
Objective The objective of the Project Approval phase is to make sure that everyone involved agrees on the requirements and that costs and estimates are reasonable.

40. Project Approval Steps
IS Review
Requirements Walkthrough
Customer Review
Development Review
Project Estimation

41. Statement of Work Objective
The objective of the Statement of Work is to estimate: Project Design Phase Only <or> Project Design and Project Development Phase. The scope of this Statement of Work will be dependent on how large the project is and if Design would be better suited to it’s own Statement of Work. A project Plan should be created and approved with Systems Development before the SOW is signed.

42. Questions?