MS Computer Science Virtual University of Pakistan

CS708 Software Requirement Engineering Viva Preparation

CS708 Software Requirement Engineering Viva Preparation

Software Requirements: A complete description of what the software system will do without describing how it will do it is represented by the software requirements. Software requirements are complete specification of the desired external behavior of the software system to be built.

Requirements Elicitation: Determining the system requirements through consultation with stakeholders, from system documents, domain knowledge, and market studies.

 Functional Requirements: Statements describing what the system does, Functionality of the system.

 Non-Functional requirements: Most non-functional requirements relate to the system as a whole. They include constraints on timing, performance, reliability, security, maintainability, accuracy, the development process, standards, etc.

  • Product requirements
    • Usability requirements
    • Efficiency requirements
      • Performance requirements
      • Space requirements
    • Reliability requirements
    • Portability requirements
  • Organizational requirements:
  • External requirements
    • Interoperability requirements
    • Ethical requirements
    • Legislative requirements
      • Privacy requirements
      • Safety requirements

 Inverse Requirements: They explain what the system shall not do. Many people find it convenient to describe their needs in this manner.

Errors of Omission: Errors of omission are most common among requirements errors.

Domain experts easily forget to convey domain knowledge to requirements engineers, because they consider that to be obvious and implicit

Errors of Commission: Errors of commission can also find their way into the requirements documents.

 Stable Requirements: Stable requirements are concerned with the essence of a system and its application domain. They change more slowly than volatile requirements.

Volatile Requirements: Volatile requirements are specific to the instantiation of the system in a particular environment and for a particular customer.

 Prototyping: It is the technique of constructing a partial implementation of a system so that customers, users, or developers can learn more about a problem or a solution to that problem.

 Object-Oriented Modeling: The main building block of all software systems is the object or class. An object is a thing, generally drawn from the vocabulary of the problem space or the solution space. A class is a description of a set of common objects. Object-oriented paradigm helps in software modeling of real-life objects in a direct and explicit fashion. It also provides a mechanism.

USE CASE: A use case specifies the behavior of a system or part of a system. It is a description of a set of sequences of actions, including variants that a system performs to yield an observable result of value to an actor. Use cases are applied to capture the intended behavior of the system under development, without having to specify how the behavior is implemented.

Actor: Actors in a process are the people involved in the execution of that process. Software engineers, System end-users, Managers of system end-users, External regulators,

Domain experts

Stake holders: Actors in a process are the people involved in the execution of that process. Software engineers, System end-users, Managers of system end-users, External regulators,Domain experts

 Requirements Specification: Building a tangible model of requirements using natural language and diagrams

Requirements Validation: It involves reviewing the requirements model for consistency and completeness

 Process Models: A process model is a simplified description of a process presented from a particular perspective.

Coarse-grain Activity Model: This type of model provides an overall picture of the process. Describes the context of different activities in the process.

Fine-grain Activity Models: These are more detailed models of a specific process, which are used for understanding and improving existing processes.

Role-action Models: These are models, which show the roles of different people involved in the process and the actions which they take.

Entity-relation Models: The models show the process inputs, outputs, and intermediate results and the relationships between them.

Closed interviews: The requirements engineer looks for answers to a pre-defined set of questions.

Open interviews: There is no predefined agenda and the requirements engineer discusses, in an open-ended way, what stakeholders want from the system.

Follow Through: Immediately after the interview, fill in your notes; be sure to jot down impressions and important ideas.

 Analysis checklists: A checklist is a list of questions which analysts may use to assess each requirement.

 Interaction matrices: Interaction matrices are used to discover interactions between requirements and to

 Ad hoc Review: A review with no formal, systematic procedure, based only individual experience

 Checklist Review: A list of items is provided to reviewers, which makes this inspection process more focused

 Defect-based Reading: Provides a set of systematic procedures that reviewers can follow, which are tailored to the formal software cost reduction notation

 Perspective-Based Reading (PBR): Researchers at Experimental Software Engineering

Group at the University of Maryland, College Park, have created Perspective-Based Reading

(PBR) to provide a set of software reading techniques for finding defects in English-language requirements documents

 Dynamic Renumbering: Some word processing systems allow for automatic renumbering of paragraphs and the inclusion of cross-references. As you re-organize your document and add new requirements, the system keeps track of the cross-reference and automatically renumbers your requirement depending on its chapter, section and position within the section

Symbolic Identification: Requirements can be identified by giving them a symbolic name which is associated with the requirement itself. For example, EFF-1, EFF-2, EFF-3 may be used for requirements which relate to system efficiency

Throw-away Prototyping: Intended to help elicit and develop the system requirements. The requirements which should be prototyped are those which cause most difficulties to customers and which are the hardest to understand. Little documentation is needed.

 Evolutionary Prototyping: Intended to deliver a workable system quickly to the customer. The requirements which should be supported by the initial versions of this prototype are those which are well-understood and which can deliver useful end-user functionality.

Approaches to Prototyping:

 Paper Prototyping: A paper mock-up of the system is developed and used for system experiments. This is very cheap and very effective approach to prototype development. No executable software is needed

‘Wizard of Oz’ Prototyping: A person simulates the responses of the system in response to some user inputs. Relatively cheap as only user interface software needs to be developed. The users interact through this user interface software and all requests are channeled to

the a person, who simulates the system’s responses.

Executable Prototyping: A fourth generation language or other rapid development environment is used to develop an executable prototype. This is an expensive option and involves writing software to simulate the functionality of the proposed system.

 Traced: An SRS is traced if the origin of its requirements is clear. That means that the SRS includes references to earlier supportive documents

 Traceable: An SRS is traceable if it is written in a manner that facilitates the referencing of each individual requirement stated therein.

Requirement Elicitation

Elicit means to gather, acquire, extract, and obtain, etc.

  • Requirements elicitation means gathering requirements or discovering requirements
  • Activities involved in discovering the requirements for the system

Requirements Elicitation Techniques

Individual, group, modeling, cognitive

Problems in Requirements Elicitation

Problems of scope, Problems of understanding, Problems of volatility

Use Case Modeling

  • Define actors and black-box use cases
  • The functional requirements of the system are defined in terms of use cases and actors
  • The use case descriptions are a behavioral view

Basics of Knowledge Acquisition

Reading, Listening, Asking, Observing

Results in large volume of information, which must be organized to make it understandable

Knowledge Structuring Techniques

Partitioning, Abstraction, Projection