Module 3

• The requirements for a system are the descriptions of the services that a system should provide and the constraints on its operation.
• this is the process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. It is also known as Requirements Engineering.
• User Requirements are statements, in a natural language plus diagrams, of what services the system is expected to provide to system users and the constraints under which it must operate.
• System Requirements are more detailed descriptions of the software system’s functions, services, and operational constraints. The system requirements document (sometimes called a functional specification)
• Functional requirements These are statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations.
• Non-functional requirements, as the name suggests, are requirements that are not directly concerned with the specific services delivered by the system to its users.
• A feasibility study decides whether or not the proposed system is worthwhile. It is a short focused study that checks •
• Interviewing, where you talk to people about what they do.
• Observation or ethnography, where you watch people doing their job to see what artifacts they use, how they use them, and so on.
• Ambiguity - The readers and writers of the requirement must interpret the same words in the same way.
• NL is naturally ambiguous so this is very difficult.
• Over-flexibility -The same thing may be said in a number of different ways in the specification.
• Lack of Modularisation -NL structures are inadequate to structure system requirements.
• Requirements validation is the process of checking that requirements define the system that the customer really wants.
• Validity checks. These check that the requirements reflect the real needs of system users. Because of changing circumstances, the user requirements may have changed since they were originally elicited.
• Completeness checks. The requirements document should include requirements that define all functions and the constraints intended by the system user.
• Consistency checks. Requirements in the document should not conflict. That is, there should not be contradictory constraints or different descriptions of the same system function.
• Realism checks. By using knowledge of existing technologies, the requirements should be checked to ensure that they can be implemented within the proposed budget for the system.
• Verifiability. To reduce the potential for dispute between customer and contractor, system requirements should always be written so that they are verifiable.
• Requirements Reviews - The requirements are analyzed systematically by a team of reviewers who check for errors and inconsistencies.
• Prototyping - This involves developing an executable model of a system and using this with end-users and customers to see if it meets their needs and expectations.
• Stakeholders experiment with the system and feedback requirements changes to the development team.
• Test-case generation - Requirements should be testable. If the tests for the requirements are devised as part of the validation process, this often reveals requirements problems
• The requirements document is the official statement of what is required of the system developers