Software Requirements

CS 422 - SOFTWARE ENGINEERING

3.5 Elicitation of Non-functional Requirements NFRs are requirements that are related to the quality aspects of the system being developed or the functionalities provided by the system.

Technical Non-functional Requirements

To elicit the technical NFRs, the analyst, client, and user must consider each type of requirement thoroughly. Depending on the type of system being developed, it is determined whether the requirements are mostly system-wide or not.

Technical Non-functional Requirements 1. Interoperability requirements - impose constraints on the types of systems with which the software has to interface. - Software systems might have to interface and communicate with other software systems and hardware devices.
Example, The system must be able to interface with all printers manufactured by company X.

Technical Non-functional Requirements 2. Maintainability requirements - impose constraints related to the ease with which the software can be fixed, adapted to new environments and technologies, or expanded.

Technical Non-functional Requirements 3. Operational requirements - impose constraints on both the physical and logical environments in which the software under development will operate.

Technical Non-functional Requirements 4. Performance requirements - impose some technical constraints on the response time delays, throughput of the system, and memory requirements.

Technical Non-functional Requirements 5. Portability requirements - impose some conditions related to the future deployment of the system. Software portability - is defined as the ease with which the software can be made to run on a different hardware platform or software environment.

Technical Non-functional Requirements 6. Reliability and availability - Reliability requirements impose some values related to the reliability of the software under development. - Availability requirements can also be used to impose an upper limit on the downtime of the software system, indicating an acceptable level of failures.

Technical Non-functional Requirements 7. Reusability requirements - impose constraints on the development of the system related to the degree of reuse.
Two types:
a. Development with reuse aims at producing software faster by using existing software components. (helps the reliability of the overall system) Development for reuse aims at producing highly maintainable software that is typically made of reusable components. (helps the maintainability of the software system and can impose specific decisions related to the software development methodologies used)

b.

Technical Non-functional Requirements 8. Robustness requirements - impose constraints related to the way the software handles abnormal and erroneous inputs and operational conditions. The requirements addressed the software behavior with respect to error recoverability and fault tolerance and can be system-wide or use case-specific requirements.

Technical Non-functional Requirements 9. Safety requirements - are needed when the software being developed deals with safety critical issues such as aviation software or power and chemical plants control software.
For example, in chemical plant control software, a fail-safety requirement might state that: In the case of software failure, a safety procedure XYZ must be activated immediately to ensure no chemical leakage takes place.

Technical Non-functional Requirements 10. Scalability requirements - impose constraints on how the software system should scale up to a high-input load at all interfaces. This requirement can force specific architectural design choices on the development team. Ideally, scalability requirements are quantifiable and are normally verified during load testing.

Technical Non-functional Requirements 11. Security requirements - are critical and need to be identified early in the software development process. (can either be a system
wide or use case-specific requirement)

- address four main security concerns:

(1) confidentiality, (2) integrity, (3) availability, and (4) accountability. The concerns are dealt with by imposing and adhering to identification, authentication, authorization, integrity, immunity, privacy, non-repudiation, survivability, physical protection, and security standards conformity requirements.

Technical Non-functional Requirements (1) Access control-related requirements, including identification, authentication and authorization are used to address confidentiality concerns at the physical level. (can be system wide or use casespecific)

Technical Non-functional Requirements (2) Integrity concerns are addressed using integrity, immunity, and privacy requirements. (can be system wide or use case-specific)
An example of a system-wide integrity requirement might state that all files saved by the software must be tamper proof so that any malicious and unauthorized modification of a file shall be detected.

Technical Non-functional Requirements (3) Availability issues are dealt with using the survivability and physical protection requirements.

Can be applicable use case-specific, as It can also be function- orsystem-wide, suchfor example, the That shall continue to provide the systemaddresses availability its user validation shall always be performed regardless of some concernseven if state that the functions might one node fails. network nodes failures. database servers shall be protected in fireproof data centers.

Technical Non-functional Requirements (4) Accountability concerns are dealt with using the non-repudiation and standards conformity requirements.
Example, could be the software and the example, the software shall environment in which it preserve a tamper-proof record operates shall conform to of every privileged access tothe ISO 17799 standard. the system.

Technical Non-functional Requirements 12. Testability requirements - impose constraints on the future testing of the developed software. - is defined as the ease with which testing can be performed.

Technical Non-functional Requirements 13. Traceability requirements - impose some constraints on the ease with which the software is traceable. - helps to meet the auditability and non-repudiation aspects of security requirements.
Examples of the two types of traceability requirements are all activities of an admin user session must be recorded by the system, and every functional requirement must be traced forward in the design, code, and testing documents.

Technical Non-functional Requirements 14. Usability requirements - address the constraints imposed by the client in its representation of the user community. - the objective for the constraints is to make the software easy to use by the various users interacting with it.

Technical Non-functional Requirements 15. User-Friendliness requirements - impose some constraints on the user experiences when interacting with the software. The constraints can have implications on the functional requirements and the graphical user interface design decisions. - Usability and user-friendliness requirements complement each other and are often seen as equivalent.

Non-Technical Non-functional Requirements

The requirements are normally system wide. However, it is possible to have a system with two types of users, admin users and normal users, with cultural requirements imposed only on normal users.

Non-Technical Non-functional Requirements 1. Cultural and Political requirements - address the cultural and political constraints that have to be considered when developing the software. - the analyst and client must be aware of the cultural sensitivities of the countries in which the software will be deployed.

Non-Technical Non-functional Requirements 2. Legal and Regulatory requirements - address the legal and regulatory issues related to the software. -Adherence to local and international laws and regulations have to be observed by the software and the process by which it is developed.

Non-Technical Non-functional Requirements 3. Conformity to standards requirements - indicate the standards that must be followed while developing the software system.
a. internal standards b. specific country standards c. military standards d. industry standards e. specific standards f. professional standards g. international standards

Example 3.2
Examples of generic system-wide NFRs for the OPS system are:
a. Must be accessible from PCs, Sun Workstations, or Macintoshes using at least Internet Explorer and Netscape web browsers. b. Must be modular software made of reusable components that era easily modifiable. c. Must have speed of access to OPS and must be, as much as possible, location-transparent. d. Must be portable to additional platforms with the least effort. e. Must be highly available with only an average of one hour a week of downtime to allow for upgrades. f. Must allow for 100 simultaneous user accesses during the first year of operations and 300 thereafter. g. Must allow encryption for private user data and only users or programs with the right access control are allowed to decrypt the data. h. Must log all critical transactions, including ordering, modifying order, or cancelling order for future use. i. Must be easy to use by novice computer users by providing contextual guidance throughout the interface. j. Must allow language support, depending on the country from which it is accessed.

Example 3.3
Examples of NFRs for the Place Order use case are: a. Private data in the Place order form must be encrypted in the order database. b. Time out should occur if the Place order form is not submitted within 20 minutes. c. Confirmation to the Place order form, once submitted, must occur within 30 seconds d. Cancellation and help should be available at any time during the ordering process.

3.6 REQUIREMENTS VALIDATION

According to the IEEE standard for requirements specifications, desirable properties of software requirements include:
1. correctness 2. completeness 3. clarity and comprehensibility 4. non-ambiguity 5. consistency 6. feasibility 7. modifiability and maintainability 8. testability 9. traceability 10. verifiability 11. reusability 12. ranking for importance and criticality

3.6 REQUIREMENTS VALIDATION

Two Approaches 1. Synthetically or constructively during their development
 To ideally eliminate or minimize 2. Analytically after errors. been developed requirements having  Although this approach involves some degree of automation, it still relies on human interactions.

3.7 REQUIREMENTS MAINTENANCE

- After the software is released, many errors might be reported by the user population. - Some of the errors might be caused by requirements and specification errors that were not caught during software development.

3.8 SOFTWARE REQUIREMENTS SPECIFICATION DOCUMENT

Three Sections: 1. Introduction 2. Overall description of the software under analysis 3. Description of the specific software functionalities, the NFRs.

Table 3.7 Template used in the IEEE recommended practice for software requirements specifications

SUMMARY
Software analysis - 1st phase of a typical software development process model - includes both the software requirements and specifications stages *Obtaining the proper software requirements is an important and crucial task in a software development project. Requirements are the foundation upon which the software architecture and design is developed. Two Types of Requirements: 1) Functional Requirements are related to the visible, user interface-driven functions to be provided by the software product. 2) NFRs are mainly quality requirements related to the attributes of the offered functionalities. (can be product wide or function-specific requirements) *Once developed, SR must be reviewed and validated. *Requirements prototyping useful method to obtain an approval on SR *Requirements management allows the proper handling & maintenance of the requirement

Thank You!
Prepared by: Sempron, Allyn BSC CS 4A

~THE END~