1 CSC-3324: Chapter 4 Title: What is a requirement? Mandatory reading: Sommerville 6, 7 th ed., Chap.: 7.
Published byModified over 5 years ago
Presentation on theme: "1 CSC-3324: Chapter 4 Title: What is a requirement? Mandatory reading: Sommerville 6, 7 th ed., Chap.: 7."— Presentation transcript:
1 CSC-3324: Chapter 4 Title: What is a requirement? Mandatory reading: Sommerville 6, 7 th ed., Chap.: 7
Soft. Eng. I, Spring 072 Wrap up on Chap. 1, 2 & 3... What is Software Engineering (SE) ? The major goal of SE is to produce good software cost effectively… What is good software? In order to produce good software, we need to follow a good SE process… What is a good process? Some SE process models are widely used and universally recognized… Before launching any SE process, we should first be perform a feasibility study... Software engineering is concerned with theories, methods and tools for professional software development Maintainability, Dependability, Efficiency, Usability Understandable, Visible, Supported, Accepted, Reliable, Rapid, etc. Structured set of activities (steps) required to develop a software system.... The waterfall model Separate and distinct phases of specification and development Prototyping development Specification and development are interleaved Component-based development The system is assembled from existing components A quick and cheap study of the project requirements in order to assess the business opportunity, the technology enablers and the schedule...
Soft. Eng. I, Spring 073 Requirements Engineering... The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed... The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process…. Engineering consists of collecting, analyzing and documenting the requirements in order to better understand/Present them...
Soft. Eng. I, Spring 074 What is a requirement? An attribute that the projected system must fulfill… It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. Examples… The word Requirement is not uniformly used...
Soft. Eng. I, Spring 075 Some common problems... Precision... Completeness... Consistency...
Soft. Eng. I, Spring 076 Types of requirements... User requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers… (Usually during the Feasibility study…) Information system requirements A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor(Usually during the Req. Eng.…) Software specification A detailed software description which can serve as a basis for a design or implementation. Written for developers (Design)
Soft. Eng. I, Spring 077 Functional and non-functional requirements Functional requirements Non-functional requirements Domain requirements Requirements that come from the application domain of the system and that reflect characteristics of that domain
Soft. Eng. I, Spring 078 Functional requirements Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. Functional user requirements may be high-level statements of what the system should do but functional system requirements should describe the system services in detail
Soft. Eng. I, Spring 079 Non-functional requirements Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Constraints are I/O device capability, system representations, etc. Reliability, Response time and Storage requirements. Mandating CASE system, programming language or development method
Soft. Eng. I, Spring 0710 Domain requirements Derived from the application domain and describe system characteristics and features that reflect the domain May be new functional requirements, constraints on existing requirements or define specific computations If domain requirements are not satisfied, the system may be unworkable