UNIT III

REQUIREMENTS ANALYSIS

Identification of Functional and Non Functional Requirements: In general, requirements are partitioned into functional requirements and non-functional requirements. Functional requirements are associated with specific functions, tasks or behaviors the system must support, while non-functional requirements are constraints on various attributes of these functions or tasks. In terms of the ISO quality characteristics for evaluation, the functional requirements address the quality characteristic of functionality while the other quality characteristics are concerned with various kinds of non-functional requirements. Because non-functional requirements tend to be stated in terms of constraints on the results of tasks which are given as functional requirements (e.g., constraints on the speed or efficiency of a given task), a task-based functional requirements statement is a useful skeleton upon which to construct a complete requirements statement. That is the approach taken in this work. It can be helpful to think of non-functional requirements as adverbially related to tasks or functional requirements: how fast, how efficiently, how safely, etc., is a particular task carried out by a particular system? Non-functional requirement: A Non-Functional Requirement is usually some form of constraint or restriction that must be considered when designing the solution.In systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions. In general, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be. Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are "constraints", "quality attributes", "quality goals" and "quality of service requirements". Qualities, that is, non-functional requirements, can be divided into two main categories: Execution qualities, such as security and usability, which are observable at run time. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system. Examples A system may be required to present the user with a display of the number of records in a database. This is a functional requirement. How up-to-date this number needs to be is a non-functional requirement. If the number needs to be updated in real time, the system architects must ensure that the system is capable of updating the displayed record count within an acceptably short interval of the number of records changing. Non-functional requirements address aspects of the system other than the specific functions it performs. These aspects include system performance, costs, and such general system characteristics as reliability, security, and portability. The non-functional requirements also address aspects of the system development process and operational personnel. System-Related Non-Functional Requirements Non-functional system requirements include some or all of the following:
a. performance i. time ii. space b. operational environment

i. hardware platform ii. software platform iii. external software interoperability c. standards conformance d. general characteristics i. reliability ii. robustness iii. accuracy of data iv. correctness v. security vi. privacy vii. safety viii. portability ix. modifiability and extensibility x. simplicity versus power

Process-Related Non-Functional Requirements

Non-functional process requirements include some or all of the following: a. b. c. d. development time development cost software life cycle constraints system delivery i. extent of deliverables ii. deliverable formats e. installation i. developer access to installed environment ii. phase-in procedures to replace existing system f. standards conformance g. reporting h. marketing i. pricing i. target customer base j. contractual requirements and other legal issues Personnel-Related Non-Functional Requirements Non-functional personnel requirements include some or all of the following: a. for developers: i. credentials ii. applicable licensing, certification b. for users: i. skill levels ii. special accessibility needs iii. training

Other examples: Accessibility Audit and control Availability (see service level agreement) Certification Dependency on other parties Documentation Efficiency (resource consumption for given load) Effectiveness (resulting performance in relation to effort)

Extensibility (adding features, and carry-forward of customizations at next major version upgrade) Legal and licensing issues Interoperability Maintainability Open Source Performance / Response time (see Performance Engineering) Platform compatibility Price Portability Quality (e.g. Faults Discovered, Faults Delivered, Fault Removal Efficacy) Reliability (e.g. Mean Time Between Failures - MTBF) Resource constraints (processor speed, memory, disk space, network bandwidth etc. ) Response time Robustness Scalability (horizontal, vertical) Security Software, tools, standards etc. Compatibility Stability Safety Supportability Testability Usability by target user community

Non-Functional requirements tend to identify user constraints and system constraints. A system constraint is a constraint imposed by the system and not dictated by a Business Need. Since system constraints are part of a solution, they should be documented in the System Specifications document. Functional Requirements: Functional requirements capture the intended behavior of the system. This behavior may be expressed as services, tasks or functions the system is required to perform. In product development, it is useful to distinguish between the baseline functionality necessary for any system to compete in that product domain, and features that differentiate the system from competitors products, and from variants in your companys own product line/family. Features may be additional functionality, or differ from the basic functionality along some quality attribute (such as performance or memory utilization). One strategy for quickly penetrating a market, is to produce the core, or stripped down, basic product, and adding features to variants of the product to be released shortly thereafter. This release strategy is obviously also beneficial in information systems development, staging core functionality for early releases and adding features over the course of several subsequent releases. In many industries, companies produce product lines with different cost/feature variations per product in the line, and product families that include a number of product lines targeted at somewhat different markets or usage situations. What makes these product lines part of a family, are some common elements of functionality and identity. A platform-based development approach leverages this commonality, utilizing a set of reusable assets across the family. These strategies have important implications for software architecture. In particular, it is not just the functional requirements of the first product or release that must be supported by the architecture. The functional requirements of early (nearly concurrent) releases need to be explicitly taken into account. Later releases are accommodated through architectural qualities such as extensibility, flexibility, etc. The latter are expressed as non-functional requirements. In software engineering, a functional requirement defines a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs (see also software). Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish. Behavioral requirements describing all the cases where the system uses the functional requirements are captured in use cases. Functional requirements

are supported by non-functional requirements (also known as quality requirements), which impose constraints on the design or implementation (such as performance requirements, security, or reliability). How a system implements functional requirements is detailed in the system design. As defined in requirements engineering, functional requirements specify particular results of a system. This should be contrasted with non-functional requirements which specify overall characteristics such as cost and reliability. Functional requirements drive the design of a system, while non-functional requirements drive the architecture of a system. Typically, a requirements analyst generates use cases after gathering and validating a set of functional requirements. Each use case illustrates behavorial scenarios through one or more functional requirements. Process A typical functional requirement will contain a unique name and number, a brief summary, and a rationale. This information is used to help the reader understand why the requirement is needed, and to track the requirement through the development of the system. The crux of the requirement is the description of the required behavior, which must be clear and readable. The described behavior may come from organizational or business rules, or it may be discovered through elicitation sessions with users, stakeholders, and other experts within the organization. Many requirements may be uncovered during the use case development. When this happens, the requirements analyst should create a placeholder requirement with a name and summary, and research the details later, to be filled in when they are better known Software requirements must be clear, correct, unambiguous, specific, and verifiable.

Functional Requirements Template

Functional Requirement defines a function of a software system and how the system must behave when presented with specific inputs or conditions. These may include calculations, data manipulation and processing and other specific functionality. A typical functional requirement has a unique name, number, summary, and a rationale. Use this template to: Specify particular behaviors of a system. Use the requirements to generate use cases. Each use case describes one or more functional requirement. Help the reader understand why a requirement is needed. Track requirements through the development of the system. Capture the scope, business objectives, and functional and non-functional requirements of the current/proposed system.

Identification of Performance Requirements:

The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements. In identifying and quantifying performance requirements, it is important to identify the reasoning behind a particular requirement. This is part of the general capacity planning process. Users might be basing their statements of requirements on assumptions about the logic of the program that do not match the programmer's assumptions. At a minimum, a set of performance requirements should document the following:

The maximum satisfactory response time to be experienced most of the time for each distinct type of usercomputer interaction, along with a definition of most of the time. Response time is measured from the time that the user performs the action that says "Go" until the user receives enough feedback from the computer to continue the task. It is the user's subjective wait time. It is not from entry to a subroutine until the first write statement. If the user denies interest in response time and indicates that only the result is of interest, you can ask whether "ten times your current estimate of stand-alone execution time" would be acceptable. If the

answer is "yes," you can proceed to discuss throughput. Otherwise, you can continue the discussion of response time with the user's full attention.

The response time that is minimally acceptable the rest of the time. A longer response time can cause users to think the system is down. You also need to specify rest of the time; for example, the peak minute of a day, 1 percent of interactions. Response time degradations can be more costly or painful at a particular time of the day. The typical throughput required and the times it will be taking place. This is not a casual consideration. For example, the requirement for one program might be that it runs twice a day: at 10:00 a.m. and 3:15 p.m. If this is a CPU-limited program that runs for 15 minutes and is planned to run on a multiuser system, some negotiation is in order. The size and timing of maximum-throughput periods. The mix of requests expected and how the mix varies with time. The number of users per machine and total number of users, if this is a multiuser application. This description should include the times these users log on and off, as well as their assumed rates of keystrokes, completed requests, and think times. You may want to investigate whether think times vary systematically with the preceding and following request. Any assumptions that the user is making about the machines the workload will run on. If the user has a specific existing machine in mind, make sure you know that early on. Similarly, if the user is assuming a particular type, size, cost, location, interconnection, or any other variable that will constrain your ability to satisfy the preceding requirements, that assumption also becomes part of the requirements. Satisfaction will probably not be assessed on the system where the program is developed, tested, or first installed.

Identification of Safety Requirements Analysis:

Functional requirements which are the logical business or user functions the software must perform. These include elementary processes that must be supported to input, process, manipulate, output, and interface data to, from, and within the software. Functional requirements describe what it is that a customer needs to be able to do with the software. Statements of services the system should provide how the system should react to particular inputs and how the system should behave in particular situations. The user shall be able to search either all the databases or select a subset from it. Examples of Functional Requirement The system shall provide appropriate viewers for the user to read documents. Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the accounts permanent storage area. Identify Functional Requirements: Identify and articulate the activities, tasks, or actions required to achieve the stated system mission. How to Identify requirements? depends on the kind of system you are going to develop. We focus here on interactive systems: domain analysis finding out who is the user? interviews observation participatory design Domain Analysis Are there similar programs? What scope do they have? What problems do their users have? Is the area subject to legal regulations? How do they look like? What are the problems in the use contexts? What kind of work will be supported? How does the organization look like

2) Who is the user? Primary : end users Secondary : occasional users or users through an intermediary Tertiary : affected by the introduction of the System customer <==> user(s) Interviews structured - if you know exactly what you do not know unstructured - if you do not have any idea what to ask for semi-structured - if you have some idea and would like to know more, - if you are aware that their might be facts you do not have any idea about. Use an Interview guideline Observation The time man. The fly on the wall. Participatory observation: becoming a short term apprentice to the user. Observing participation: working for some time in the organization to be supported. Ethnographic studies. Attention: Keep focus on the subject of the requirements specification! Participatory study future work shops design work shops visualizing design in mock-ups, scenarios, system visions, prototypes users can even act as project members and participate throughout the whole project. Identify Non Functional Requirements (NFR) : Nonfunctional requirements are the technology independent user/business constraints that the software must meet. e.g., Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Nonfunctional requirements include quality and performance requirements such as portability, usability, security, dependability, reliability, and speed. Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless. Non-functional Requirements Identification Product requirements Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. Organisational requirements Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc. External requirements Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc. Technical requirements Requirements for a specific hardware/software configuration or a particular technical configuration that must be delivered. Non-functional requirements examples Product requirement It shall be possible for all necessary communication between the ABC system and the user to be expressed in the standard Chinese character set

Organisational requirement The system development process and deliverable documents shall conform to the process and deliverables defined in company standard SS-101 External requirement The system shall not disclose any personal information about customers apart from their name and reference number to the system operators Technical requirement An Oracle database must be used.

Functional vs. Non-Functional Functional requirements describe what the system should do functions that can be captured in use cases behaviours that can be analyzed by drawing sequence diagrams, statecharts, etc. and probably trace to individual chunks of a program Non-functional requirements are global constraints on a software system e.g. development costs, operational costs, performance, reliability, maintainability, portability, robustness etc. Often known as software qualities, or just the ilities Usually cannot be implemented in a single module of a program Identification of Performance Requirements: Identify and articulate the performance capabilities required to successfully meet the stated system mission. Define Measures of Performance: Define the metrics by which the performance of the system will be assessed. Measures of performance (MOPs) are defined to a greater amount of specificity than measures of effectiveness. Identification of safety Requirements Define the safety factors including equipment/system design features, performance specifications and training that reduces the potential for human or machine errors or failures that cause injury or death within the constraints of operational effectiveness, time and cost throughout the equipment/system life cycle Develop Safety Guidelines: Provide guidance for system development to ensure that safety factors are taken into consideration early in the design process.

Feasibility & Internal Compatibility of System Requirements: A feasibility study is an evaluation and analysis of the potential of the proposed project which is based on extensive investigation and research to give full comfort to the decisions makers. Feasibility studies aim to objectively and rationally uncover the strengths and weaknesses of an existing business or proposed venture, opportunities and threats as presented by the environment, the resources required to carry through, and ultimately the prospects for success. In its simplest terms, the two criteria to judge feasibility are cost required and value to be attained. As such, a well-designed feasibility study should provide a historical background of the business or project, description of the product or service, accounting statements, details of the operations and management, marketing research and policies, financial data, legal requirements and tax obligations. Generally, feasibility studies precede technical development and project implementation. Types of feasibility: 1)Technical Feasibility Here one ask the question like : can the personnels work with existing technology??? Are the personnel updated with latest technology??? Are they aware of the technical knowledge??? If not what would be the solution.. 2) Economic feasibility As the world denotes that the economic feasibility means more benefit at less expenditure .So every organization must keep in mind while recruitments of the personnels that more people should not be employed than required as it can raise the cost. 3) Motivational feasibility Motivation plays a vital role in overall improvement in terms of efficiency of personnels. As through motivation more and more work with greater efficiency can be taken away from employees Different ways of motivations are: Performance appraisals Training and development Improving working condition as par their health and security. Incentives and perks etc. 4) Operational feasibility Before switching to new technology, it mainly examines whether the employees at work are comfortable with organizational frame work.. Are the Requirements, specifications and design clearly explained to the employees, so that they conduct their operations successfully. Political feasibility It is perhaps the most power full type of feasibility. As every political system is biased. Because government issues, new polices which can effect the moral of the personnels at a larger extent. Hence these are the different types of feasibility having different effects on the conduct of personnels.

Analyse Internal Compatibility of System Requirements:

Examine the system requirements (including mission requirements, human requirements, and job/task requirements) for discrepancies or conflicts within the requirements themselves and for variances with respect to established system characteristics such as infrastructure, interfaces with other systems, and user characteristics. Examine the system requirements for estimates of feasibility.

Definition of Human Requirements Baseline:

Establish the baseline system requirements that ensure human capabilities and limitations that directly contribute to, or constrain, total system performance are accounted for.

Task Design and Analysis

Based on the functions allocated to humans, develop the human tasks required to ensure successful completion of the function. Task development is based on a decision analysis approach. This produces a depiction of the task in terms of the cues to alert the human that a decision/action needs to be taken, the decisions/action to be made, the information required to support the decision, and mechanisms to implement the results of the decision/action. The critical characteristics and interactions are also articulated.
Design Human Interfaces:

Design the interfaces between humans and hardware, software, and other humans. Both physical and procedural interfaces should be considered. Develop individual and team interfaces.
Estimate Performance, Workload, and Manning Levels

Estimate the physical (perceptual, psychomotor, physiological, etc.) and cognitive workload levels of individuals and teams within the system. Define workload stressors and their effects on human performance, operator coping strategies, and the effects of task neglect/delay. Workload and the resultant manning and training requirements are to be optimized to meet required performance levels.