Requirement Engineering :
Requirement Engineering (RE) is the science and discipline concerned with analyzing and documenting requirements.
(1) A condition or capability needed by a user to solve a problem or achieve an objective.
(2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
(3) A documented representation of a condition or capability as in (1) or (2).
i. Type: the source and contractual applicability ii. Application: the object of a requirement iii. Compliance Level: the depth of compliance mandated for a requirement iv. Priority: relative importance of a requirement
Requirement Type :
Primary requirements: Sources: Contract or pre-contract document established by management or marketing Derived requirements: Derived form a primary requirement Derived from a
Requirement Application :
Product parameter: applies to a product or service to be developed Qualitative – not directly measurable children (derived requirements) refine which provide quantifiable criteria should be met Quantitative – measurable children (derived requirements) can be generated for the purpose of specifying particular approaches to meet this measurable requirement Program Parameter: activities associated with enabling the creation of the product/service Task: effort to be performed Compliance Evaluation: methodology for measuring compliance Regulatory: administrative elements
Requirement Compliance Level :
Mandatory: must be implemented Guidance: desirable that it be implemented Information: non-binding statements which significantly influence the context, meaning, and understanding of other requirements
Requirement Priority :
Characterize the relative importance of a requirement Basis for trade studies Unlike the other characteristics the priority depends on company needs. A Good Set of Requirements is … Correct Unambiguous Complete Consistent Ranked for importance and/or stability Verifiable
System vs. Software :
System Requirement Engineering is the science and discipline concerned with analyzing and documenting system requirements. origin: user needs Software Requirement Engineering is the science and discipline concerned with analyzing and documenting software requirements. origin: system requirements and/or specification BUT: For software-intensive systems software people should be involved in the elicitation of the system requirements!
Requirement Engineering Elements :
(1) Requirement Elicitation (2) Requirement Analysis (3) Requirement Specification (4) Requirement Validation (5) Requirement Management
Requirement Elicitation :
Requirement Elicitation: the process through which the customer and developer discover, review, articulate, and understand the users’ needs and constraints on the software and development activities Requirements elicitation is about discovering what requirements a system should be based upon This doesn’t involve just asking stakeholders what they Want. It requires a careful analysis of: The organization The application domain Organization processes where the system will be used To determine what the stakeholders Need.
Requirement Analysis :
Requirement Analysis: the process of analyzing the customers’ and users’ needs to arrive at a definition of the requirements requirements analysis. (1) The process of studying user needs to arrive at a definition of system, hardware, or software requirements. (2) The process of studying and refining system, hardware, or software requirements.
Analysis & Negotiation :
The analysis has to establish an agreed set of requirements which are complete, consistent, and unambiguous. Such a set can be used as the basis for systems development. Negotiation: Stakeholders often disagree over requirements. Therefore they need to negotiate to try to reach agreement.
Requirements for Complex Systems :
A system of any but the smallest size will be decomposed into a hierarchy of elements (partitioning): This is reflected at the requirement level by: (1) Allocation: assigning requirements to elements (2) Flowdown: requirements which respond to the allocated highel level requirements (3) Traceability: keep track of the dependencies
Requirements vs. Design :
Distinction: Design solution: HOW to achieve something Requirements: WHAT to achieve Two cases where a requirements and desigin solutions are mixed up: The customer mandates a design solution as a requirement Design solution (HOW): “provide a database for X” Requirements (WHAT): “capabilities for navigation and sort for X” Otherwise: Restrict design space. Risk to miss requirements: ask WHY! Risk to miss requirements: ask WHY! A derived requirement which is actually a design solution and no requirement See allocation and flowdown Often alternation of requirements analysis and design One person’s design is the next person’s requirements
Advantages of Modular Programming :
It is easier and less costly to change features, add features or correct errors after deployment. It is easier to write and debug the program. It is easier to manage since more difficult modules can be skilled programmers and easy modules to junior programmers. One can divide a large, complex problem into each of manageable complexity. The modular concept fits in well with top-down design. Formal modular interface definition may be a especially helpful in "organization" a bottom-up, or a two-stage design, first bottom-up, and then top-down.
Disadvantages of Modular Programming :
Because there are few formal design techniques, it is difficult to learn, although the principles are clear. Modular programming requires more design effort and care. Many programmers are reluctant to try new modules can be given to more things, including modular design. Modular programming may require slightly a number of modules more memory space and run time. To avoid slow processing, in some operating systems one may have to ensure that modules that call each other frequently are in the same machine page.