Software Requirements

Definition
‡ The requirements for a system are the description of the services provided by the system and it¶s operational constraints. ‡ The requirements reflect the needs of the customers for a system and help solve a number of problems such as controlling a device, placing an order or finding information. ‡ A requirement is simply a high level, abstract statement of a service that a system should provide or a constraint on a system.

Types of requirements
‡ User Requirements- These are statements in a natural language plus diagrams of what services the system is expected to provide and the constraints under which the system must operate. ‡ System Requirements- These requirements set out the system¶s functions, services and operational constraints in detail. The system requirements produce a document which should be precise and should define exactly what is to be implemented. ‡ Functional requirements- These are statement of services the system should provide, hoe the system should react to particular inputs and how the system should behave in a particular situation. ‡ Non- Functional requirements- These are the constraints on the services and functions offered by the system. They include timing constraints, constraints on the development process and standards. ‡ Domain requirements- These are the requirements that come from the domain of the system and system environment.

Types of non-functional ‡ Product Requirements (Usability, Efficiency, Reliability, Portability) requirements the product behavior, how fast a system These requirements specify
should execute, how much memory does it use. ‡ Organizational requirements (Delivery, Implementation, Standards) These requirements are derived from policies and procedures in the customer¶s and developer¶s organization. ‡ External requirements (Interoperability, Ethical, Legislative) - These cover all requirements derived from factors external to the system and its development process.

Metrics for non-functional requirements
‡ Size- Depends on no. of bytes of space used.

‡ Speed- Depends on transactions, response time and no. of users.

‡ Ease of use- Training time and no of help frames ‡ Reliability- Mean time to failure and rate of failure occurrence ‡ Robustness- Time to restart and %age of failure occurrence ‡ Portability- No. of target systems and %age of target dependent statements.

Notations for requirement specifications‡ Structured Natural Language- Defines standard forms or templates in natural language. ‡ Design Description language- Defines the operational level characteristics like pre-conditions, post-conditions and functions. ‡ Graphical notation- State changes, state diagrams and data flow diagrams. ‡ Mathematical Specification- Notations based on mathematical concepts like algebraic specification and finite state machines.

Software Requirements Specification (SRS)
‡ The software requirements document also called the software requirements specification (SRS) is the official statement of what the system developers should implement. It includes user requirements and system requirements. It is used by all people in the organization including the developers, users, testers and managers. Format of SRS‡ Introduction- Purpose of requirements document, Scope of product, Definitions, acronyms and abbreviations, references and overview of remaining document. ‡ General Description- Product perspective, product functions, user characteristics, general constraints, assumptions and dependencies. ‡ Specific requirements- Functional, non-functional and interface requirements. ‡ Appendices ‡ Index

Requirements Engineering Process
‡ The goal of the requirement engineering process is to create and maintain a system requirement document. The overall process includes four high level requirement engineering sub processes. The RE processes are concerned with‡ Assessing whether the system is useful to the business (feasibility study). ‡ Discovering requirements (elicitation and analysis). ‡ Converting these requirements to standard form. (Specification). ‡ Checking that the requirements actually define the system that the customer wants. Validation)

Feasibility Study
‡ The input to the feasibility study is a set of preliminary business requirements, an outline description of the system and how the system is intended to support business process. ‡ The result of the feasibility study is a report that recommends whether or not it is worth carrying on with requirements engineering. A feasibility study aims to answer the following questions‡ 1. Does the system contribute to the overall objective of the organization? ‡ 2. Can the system be implemented using the current technology and within the given cost and schedule constraints? ‡ 3. Can the system be integrated with other systems which are already in place?

Requirements elicitation and analysis

‡ In this activity, software engineers work with customers and system end-users to find out about the application domain, what services the system should provide, the required performance of the system, hardware constraints and so on. ‡ Various methods of requirements discovery are‡ i) Viewpoints ‡ ii) Scenarios ‡ iii) Ethnography ‡ iv) Structured analysis ‡ v)Use-Cases ‡ vi) Prototyping

Viewpoints
‡ Viewpoints help in the elicitation process. In analysis it recognizes multiple perspectives and provides framework for discovering conflicts in the requirements. Types of viewpoints‡ Interactive Viewpoints- These represent people or systems that interact directly with the system (interfaces). ‡ Indirect Viewpoints- These represent stakeholders who do not use the system themselves but who use requirements in some way. (Managers). ‡ Domain Viewpoints- They represents domain characteristics and constraints that influence the system

Interviewing
‡ Interviewing is the process of questioning the users. Formal and Informal interviews with the stakeholders are part of most requirement engineering processes. Questions are put about the system they use and system to be developed. ‡ Types of interviews‡ Closed Interviews- Stakeholders answer pre-defined questions. ‡ Open Interviews- There is no pre-defined agenda and questions can be asked on any topic.

Scenarios
‡ Scenarios are real life examples, which are used to understand how people interact with software system. Requirement engineering is used to formulate the actual system and detail. ‡ Each scenario covers one possible interaction. A scenario can be depicted as follows‡ Start->Flow of events->What can go wrong->Other activities>Finish

Use-cases
‡ Use-Case is a fundamental feature of UML notation. Use Cases identify the individual interactions with the system. They can be documented with text or linked to UML model that develop scenario in more detail. ‡ Use-cases involve‡ 1. Actors ‡ 2. Objects they interact with ‡ 3. Operations associated with these objects

Ethnography
‡ It is an observational technique. It can be used to understand social and organizational requirements. An analyst immerses himself in the working environment where the system will be used. He makes notes of day to day tasks and understands complex and dynamic behavior which may be oblivious to the user.
Two types of requirements can be understood‡ Requirements that are derived from the way in which people work. ‡ Requirements that are derived from cooperation and awareness of other people activities

Requirements Validation
‡ Requirements Validation is concerned with showing that the requirements actually define the system that the customer wants. Requirements validation is important because errors in a requirement document can lead to extensive rework costs when they are discovered during development or after the system is in service. ‡ Steps in requirements validation areValidity Checks ± Identify functions or requirements that are different from the stated ones. Consistency Checks- Requirements in the document should not conflict and there are no contradictory constraints or descriptions. Realism Checks- Using knowledge of existing technology the requirements should be checked to ensure that they could actually be implemented. Verifiability- To reduce the potential for dispute between customer and contractor, system requirements should always be written so that they are verifiable

Requirements Management
‡ The requirements for large software systems are always changing. Once end users have experience of a system they discover new needs. Requirements management is the process of understanding and controlling changes to system requirements. There are two types of requirements‡ Enduring Requirements- These are relatively stable requirements that derive from the core activity of the organization and which relate directly to the domain of the system. ‡ Volatile Requirements- These are the requirements which are likely to change during the system development process or after system has become operational.

System Models
‡ A widely used technique is to document system specification as a set of system models. These are graphical representations that describe business process, the problem to be solved and the system to be developed ‡ It is used in requirement analysis. ‡ Problem with this technique is that it is an abstraction which simplifies and picks out the most salient features.

Types of System Models
‡ Data flow model- It shows how data is processed at different stages in the system. ‡ Composition model- A composition or aggregation model shows how entities in the system are composed of other entities. ‡ Architectural model- It shows the principal subsystems that make up a system. ‡ Classification model- These are object/class or inheritance models which shows how entities have common characteristics. ‡ Stimulus-response model- A stimulus response model or a state transition diagram shows how the system reacts to internal and external events. ‡ Context Models- In the requirements elicitation process it is important to know system boundary. System boundary is decided by social and organizational concerns.

‡ System context models help in interaction between current system and the outside system. ‡ Process Model- Process model describes various processes involved for a particular objective. ‡ Behavioral Model- It describes the overall behavior of the system. ‡ Data Flow Model- Data Flow Models are a graphical way of showing how data is processed by a system. They should be used to model the way in which data is processed by an existing system. ‡ State Machine Model- The state machine model shows the system states and events that cause transition from one state to another. This type of model is often used for modeling real-time system because these systems are often driven by stimuli from system environment. In UML state machine models are represented with state charts. ‡ Object Models- It is used for interactive systems development. Object models developed during requirement analysis may be used to represent both system data and it¶s processing. Is consists of class and objects.

‡ An object class is an abstraction over a set of objects that identifies that identifies common attributes and services or operations provided by each object.UML is a standard for object oriented modeling. ‡ Inheritance Models- After classes have been identified they are arranged in a taxonomy. Taxonomy is a classification scheme that shows how an object class is related other object classes through common attributes and services.

Formal Specification
‡ The term formal method is used to refer to any activities that rely on mathematical representation of software including formal system specification, specification analysis and proof, transformational development and program verification. ‡ Formal specification in the software process involves two main methods‡ Algebraic Approach- Here system is described in terms of operation and relationship. ‡ A model based approach- In this method model of the system is built using mathematical constructs such as sets and sequences and system operations as defined by how they modify the system state.

Algebraic Approach
‡ Algebraic Approach- The algebraic approach was designed for abstract data type specification. It consists of the following parts‡ Specification Structuring- Organize the informal specification into a set of abstract data types or object classes. ‡ Specification Naming- Establish a name for each abstract type specification. ‡ Operation selection- Choose a set of operations for each specification. ‡ Informal operator selection- Write an informal specification of each operation. ‡ Syntax definition- Define the syntax of the operation and the parameter of each. ‡ Axiom definition- Define the semantics of the operations by describing the conditions that are always true for different operation combinations.

Model Based Specification
‡ Model Based Specification- Various tools include VDM, B, and Z ‡ Z- In Z systems are modeled using sets and relations between sets. The Z schema is used to represent system inputs, system outputs and state variables.

Requirements Specification
‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ There are a number of techniques of specifying requirements. Structured Natural Language Specification and Description Language Graphical Notation or Modeling Notation Mathematical specification or Algebraic specification Functionality Tree Behavior Table Fact based collaboration modeling methodology (FBCM)

Structured Natural Language
‡ Natural Language is often used to write system requirement specifications as well as user requirements. ‡ Another form is structured natural language which is a way of writing requirements in a standard way. ‡ The advantage is it maintains most of expressiveness and understandability of natural language but ensures uniformity.

Structured Natural Language ( Example)
‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ Function- Compute the cash and amount and withdraw cash (ATM) Description- Allow customer to withdraw cash. Inputs- PIN, Account type, Cash Amount Outputs- Transaction Slip Destination- Cash slot Action- Input the PIN and cash amount, verify the pin and withdraw the cash. Requires- Access to customer database Pre-condition- Access to database and cash Post-condition- Update customer account Side effects- Low cash, No transaction

Specification and Description Language
‡ SDL is a specification language targeted at unambiguous specification and description of the behavior of reactive and distributed systems. ‡ A system is specified as a set of interconnected abstract machines which are extensions of finite state machines (FSM) ‡ SDL is formally complete and can be used for code generation and simulation purposes.

Graphical Notation or Modeling Notation for requirement specification
‡ These modeling notations represent the system in a graphical way. ‡ The information is encapsulated in the form of a chart or a diagram. ‡ At a later stage these can be used to further design and code the system. ‡ A number of such methods are available which can be used to represent the system.

Context Model
‡ Context models are used to illustrate the boundaries of a system. ‡ Social and organizational concerns may affect the decision on where to position system boundaries. ‡ Architectural models show the a system and its relationship with other systems. ‡ An SDL system is made of five components- structure, communication, behavior, data and inheritance. ‡ The behavior of the system is explained by partitioning the system into a set of hierarchies. ‡ SDL has many versions latest being SDL-2000 accompanied by SDL-UML profile.

Process Model
‡ Process models show the overall process and the processes that are supported by the system. ‡ Data flow models may be used to show the processes and the flow of information from one process to another

Data Processing Model
‡ Data flow diagrams are used to model the system¶s data processing. ‡ These show the processing steps as data flows through a system. ‡ Intrinsic part of many analysis methods. ‡ Simple and intuitive notation that customers can understand. ‡ Show end-to-end processing of data.

State Machine Model
‡ These model the behavior of the system in response to external and internal events. ‡ They show the system¶s responses to stimuli so are often used for modeling real-time systems. ‡ When an event occurs, the system moves from one state to another. ‡ State charts are an integral part of the UML.

State charts
‡ Allow the decomposition of a model into sub models. ‡ A brief description of the actions is included following the µdo¶ in each state. ‡ Can be complemented by tables describing the states and the stimuli

Semantic Data Model
‡ Used to describe the logical structure of data processed by the system. ‡ Entity-relation-attribute model sets out the entities in the system, the relationships between these entities and the entity attributes. ‡ Widely used in database design. ‡ Can readily be implemented using relational databases. ‡ No specific notation provided in the UML but objects and associations can be used

Data Dictionary
‡ Data dictionaries are lists of all of the names used in the system models. ‡ Descriptions of the entities, relationships and attributes are also included which support name management and avoid duplication. ‡ Storeage of organizational knowledge linking analysis, design and implementation ‡ Many CASE workbenches support data dictionaries

Unified Modeling Language
‡ Devised by the developers of widely used object oriented analysis and design methods has become an effective standard for object oriented modeling. ‡ Object classes are rectangles with the name at the top, attributes in the middle section and operations in the bottom section,relationships between object classes depict linking objects. ‡ Inheritance is referred to as generalization and is shown µupwards¶ rather than µdownwards¶ in a hierarchy.

Multiple Inheritance
‡ Rather than inheriting the attributes and services from a single parent class, a system which supports multiple inheritance allows object classes to inherit from several super-classes that can lead to semantic conflicts where attributes/services with the same name in different super-classes have different semantics. ‡ Makes class hierarchy reorganization more complex.

Object Aggregation
‡ Aggregation model shows how classes which are collections are composed of other classes ‡ . ‡ Similar to the part-of relationship in semantic data models.

Object Behavior Modeling
‡ A behavioral model shows the interactions between objects to produce some particular system behavior that is specified as a usecase. ‡ Sequence diagrams (or collaboration diagrams) in the UML are used to model interaction between objects.

Mathematical or Algebraic Specification
Introduction ‡ Defines the sort (the type name) and declares other specifications that are used. Description ‡ Informally describes the operations on the type Signature ‡ Defines the syntax of the operations in the interface and their parameters Axioms ‡ Defines the operation semantics by defining axioms which characterize behavior

Functionality Tree
‡ System stimuli can be represented in two ways: ‡ 1) by grouping stimuli into stimulus sets based on functional, physical, and temporal cohesion, and ‡ 2) arranging the stimulus sets into a hierarchy called a functionality tree. ‡ Syntactically, a functionality tree is a horizontal hierarchy with the hierarchical levels arranged in columns. ‡ Each column represents a ³depth level,´ which is the hierarchical distance of the stimulus sets in that level from the ³root´ of the tree. ‡ The root consists of the stimulus sets in the leftmost column, designated as ³Level 0´ because they are zero distance from the root.

Behavior Table
‡ A behavior table is a tabular notation that serves as a container for recording the total response behavior for all stimuli of a single stimulus set in a regular and systematic way. ‡ Guideline 1: One column is created for each response classification list category. ‡ Guideline 2. One row is created for each stimulus of the stimulus set.

References
‡ Software Engineering By Somerville ‡ Software Engineering : A practioner¶s approach by Roger S Pressman ‡ Illustrations From Software Engineering Presentation By Somerville

Sign up to vote on this title
UsefulNot useful