Serial Data Transfer

In a serial link, the transmitter, or driver, sends bits one at a time, in sequence. One signal required by all serial links is a clock, or timing reference, to control the flow of data. The transmitter and receiver use a clock to decide when to send and read each bit. There are two types of serial-data formats :

- Synchronous Format : Data transfer method in which a continuous stream of data signals is accompanied by timing signals(generated by an electronic clock) to ensure that the transmitter and the receiver are in step (synchronized) with one another. The data is sent in blocks (called frames or packets) spaced by fixed time intervals. After the synchronized characters are received by the remote device, they are decoded and used to synchronize the connection. After the connection is correctly synchronized, data transmission may begin. The following is a list of characteristics specific to synchronous communication:
* There are no gaps between characters being transmitted.
* Timing is supplied by modems or other devices at each end of the connection.
* Special syn characters precede the data being transmitted.
* The syn characters are used between blocks of data for timing purposes.

- Asynchronous Format : The term asynchronous is used to describe the process where transmitted data is encoded with start and stop bits, specifying the beginning and end of each character. Asynchronous, or character-framed, transmission is used to transmit seven or eight-bit data, usually in ASCII character format. Each character has a specific start and end sequence, usually one start bit and one or two end (stop)bits.
When gaps appear between character transmissions, the asynchronous line is said to be in a mark state. A mark is a binary 1 (or negative voltage) that is sent during periods of inactivity on the line. When the mark state is interrupted by a positive voltage (a binary 0), the receiving system knows that data characters are going to follow. The following is a list of characteristics specific to asynchronous communication:
* Each character is preceded by a start bit and followed by one or more stop bits.
* Gaps or spaces between characters may exist.

Metrics for Source Code

Halstead assigned quantitative laws to the development of computer software, using a set of primitive measures that may be derived after code is generated or estimated once design is complete. The measures are :

n1 = the number of distinct operators
n2 = the number of distinct operands
N1 = the total number of operator occurrences
N2 = the total number of operand occurrences
Length: N = n1log2n1 + n2log2n2
Volume: V = Nlog2(n1 + n2)

SUBROUTINE SORT (X,N)
DIMENSION X(N)
IF (N.LT.2) RETURN
DO 20 I=2,N
DO 10 J=1,I
IF (X(I).GE.X(J) GO TO 10
SAVE = X(I)
X(I) = X(J)
X(J) = SAVE
10 CONTINUE
20 CONTINUE
RETURN
END

OPERATOR COUNT
1 END OF STATEMENT 7
2 ARRAY SUBSCRIPT 6
3 = 5
4 IF( ) 2
5 DO 2
6 , 2
7 END OF PROGRAM 1
8 .LT. 1
9 .GE. 1
10 GO TO 10 1
n1 = 10 N1 = 28
n2 = 7 N2 = 22

Component Level Design Metrics

Component level design metrics for software components focus on internal characteristics of a software component and include measures of the three Cs - module cohesion, coupling, and complexity.

- Cohesion Metrics :It defines a collection of metrics that provide an indication of the cohesiveness of a module.The metrics are defined in terms of five concepts :
* Data slice - data values within the module that affect the module location at which a backward trace began.
* Data tokens - Variables defined for a module
* Glue Tokens - The set of tokens lying on multiple data slices
* Superglue tokens - The set of tokens on all slices
* Stickiness - of a glue token is proportional to number of data slices that it binds
* Strong Functional Cohesion
SFC(i) = SG(i)/tokens(i)

- Coupling Metrics : Module coupling provides an indication of the connectedness of a module to other modules, global data, and the outside environment.
* Data and control flow coupling
di = number of input data parameters
ci = number of input control parameters
d0 = number of output data parameters
c0 = number of output control parameters
* Global coupling
gd = number of global variables used as data
gc = number of global variables used as control
* Environmental coupling
w = number of modules called (fan-out)
r = number of modules calling the module under consideration (fan-in)
* Module Coupling:
mc = 1/ (di + 2*ci + d0 + 2*c0 + gd + 2*gc + w + r)
mc = 1/(1 + 0 + 1 + 0 + 0 + 0 + 1 + 0) = .33 (Low Coupling)
mc = 1/(5 + 2*5 + 5 + 2*5 + 10 + 0 + 3 + 4) = .02 (High Coupling)

Class Oriented Metrics - MOOD Metrics Suite

The MOOD metrics set refers to a basic structural mechanism of the OO paradigm as encapsulation (MHF and AHF), inheritance (MIF and AIF), polymorphisms (PF), message-passing (CF) and are expressed as quotients. The set includes the following metrics:

- Method Hiding Factor (MHF)
MHF is defined as the ratio of the sum of the invisibilities of all methods defined in all classes to the total number of methods defined in the system under consideration. The invisibility of a method is the percentage of the total classes from which this method is not visible. A low MHF indicates insufficiently abstracted implementation. A large proportion of methods are unprotected and the probability of errors is high. A high MHF indicates very little functionality. It may also indicate that the design includes a high proportion of specialized methods that are not available for reuse. An acceptable MHF range of 8% to 25% has been suggested but we neither endorse or criticize this view.
note : inherited methods not considered.
- Attribute Hiding Factor (AHF)
AHF is defined as the ratio of the sum of the invisibilities of all attributes defined in all classes to the total number of attributes defined in the system under consideration.
- Method Inheritance Factor (MIF)
MIF is defined as the ratio of the sum of the inherited methods in all classes of the system under consideration to the total number of available methods (locally defined plus inherited) for all classes.
- Attribute Inheritance Factor (AIF)
AIF is defined as the ratio of the sum of inherited attributes in all classes of the system under consideration to the total number of available attributes
(locally defined plus inherited) for all classes.
- Polymorphism Factor (PF)
It measures the degree of method overriding in the class inheritance tree. It equals the number of actual method overrides divided by the maximum number of possible method overrides.
PF = overrides / sum for each class(new methods * descendants)
PF varies between 0% and 100%. As mentioned above, when PF=100%, all methods are overridden in all derived classes. A PF value of 0% may indicate one of the following cases:
* project uses no classes or inheritance.
* project uses no polymorphism.
* full class hierarchies have not been analyzed.
- Coupling Factor (CF)
CF is defined as the ratio of the maximum possible number of couplings in the system to the actual number of couplings not imputable to inheritance.
CF = Actual couplings/Maximum possible couplings

Metrics for Object-Oriented Design - CK Metrics Suite Cont...

- Response For Class (RFC)
The RFC is defined as the total number of methods that can be executed in response to a message to a class. This count includes all the methods available in the whole class hierarchy. If a class is capable of producing a vast number of outcomes in response to a message, it makes testing more difficult for all the possible outcomes.

- Number of Children (NOC)
It is defined as the number of immediate subclasses.
* The greater the number of children, the greater the reuse, since inheritance is a form of reuse.
* The greater the number of children, the greater is the likelihood of improper abstraction of the parent class. If a class has a large number of children, it may be a case of misuse of sub-classing.
* The number of children gives an idea of the potential influence a class has on the design. If a class has a large number of children, it may require more testing of the methods in that class.

- Coupling between object classes (CBO)
It is defined as the count of the classes to which this class is coupled. Coupling is defined as : Two classes are coupled when methods declared in one class use methods or instance variables of the other class.
* Excessive coupling between object classes is detrimental to modular design and prevents reuse. The more independent a class is, the easier it is to reuse it in another application.
* In order to improve modularity and promote encapsulation, inter-object class couples should be kept to a minimum. The larger the number of couples, the higher the sensitivity to changes in other parts of the design, and therefore maintenance is more difficult.
* A measure of coupling is useful to determine how complex the testing of various parts of a design are likely to be. The higher the inter-object class coupling, the more rigorous the testing needs to be.

- Lack of Cohesion in Methods (LCOM)
It is defined as the number of different methods within a class that reference a given instance variable.
* Cohesiveness of methods within a class is desirable, since it promotes encapsulation.
* Lack of cohesion implies classes should probably be split into two or more subclasses.
* Any measure of disparateness of methods helps identify flaws in the design of classes.
* Low cohesion increases complexity, thereby increasing the likelihood of errors during the development process.

Metrics for Object-Oriented Design - CK Metrics Suite

In Object Oriented software development process, the system is viewed as collection of objects. The functionality of the application is achieved by interaction among these objects in terms of messages. Whenever, one object depends on another object to do certain functionality, there is a relationship between those two classes. In order to achieve perfect "separation of concern", objects should rely on the interfaces and contracts offered by another object without relying on any underlying implementation details. OO Design metrics can be a very helpful measuring technique to evaluate the design stability. Also, given a correct abstraction of layers and appropriate relationship between the classes, there are still chances that the coding process might introduce a few more vulnerability. At this stage also OO metrics can be of help to identify, if we need to pay further attention to any of the code to make it more maintainable.
There are different kinds of Object Oriented Metrics :

CLASS ORIENTED METRICS - THE CK METRICS SUITE
Chidamber and Kemerer's metrics suite for OO Design is the deepest reasearch in OO metrics investigation. They have defined six metrics for the OO design.

- Weighted Methods per Class (WMC)
It is defined as the sum of the complexities of all methods of a class.
* The number of methods and the complexity of methods involved is a predictor of how much time and effort is required to develop and maintain the class.
* The larger the number of methods in a class, the greater the potential impact on children, since children will inherit all the methods defined in the class.
* Classes with large numbers of methods are likely to be more application specific, limiting the possibility of reuse.

- Depth of Inheritance Tree (DIT)
It is defined as the maximum length from the node to the root of the tree.
* The deeper a class is in the hierarchy, the greater the number of methods it is likely to inherit, making it more complex to predict its behavior.
* Deeper trees constitute greater design complexity, since more methods and classes are involved.
* The deeper a particular class is in the hierarchy, the greater the potential reuse of inherited methods.

Introduction to Software metrics

Software metrics are an integral part of the state of the practice in software engineering. More and more customers are specifying software and/or quality
metrics reporting as part of their contractual requirements.Software metrics provide a quantitative way to assess the quality of internal product attributes, thereby enabling a software engineer to assess quality before the product is built.
Good metrics should facilitate the development of models that are capable of predicting process or product parameters, not just describing them. Thus, ideal metrics should be :
- simple, precisely definable — so that it is clear how the metric can be evaluated.
- objective, to the greatest extent possible.
- easily obtainable.
- valid — the metric should measure what it is intended to measure.
- robust—relatively insensitive to (intuitively) insignificant changes in the process or product.

Software metrics may be broadly classified as :
- Product and Process Metrics : Product metrics are measures of the software product at any stage of its development, from requirements to installed system. Product metrics may measure the complexity of the software design, the size of the final program or the number of pages of documentation produced. Process metrics, on the other hand, are measures of the software development process, such as overall development time, type of methodology used, or the average level of experience of the programming staff.
- Objective and Subjective Metrics : Objective metrics should always result in identical values for a given metric, as measured by two or more qualified observers.
For subjective metrics, even qualified observers may measure different values for a given metric, since their subjective judgment is involved in arriving at the measured value.
- Primitive and Computed Metrics : Primitive metrics are those that can be directly observed, such as the program size (in LOC), number of defects observed in unit testing, or total development time for the project. Computed metrics are those that cannot be directly observed but are computed in some manner from other metrics.

Control Structure Testing : Loop testing

Loops are the basis of most algorithms implemented using software. However, often we do consider them when conducting testing. Loop testing is a white box testing approach that concentrates on the validity of loop constructs. Four loops can be defined: simple loops, concatenate loops, nested loops, and unstructured loops.

- Simple Loops, where n is the maximum number of allowable passes through the loop.
o Skip loop entirely.
o Only one pass through loop.
o Two passes through loop.
o m passes through loop where m o n-1, n, and n+1 passes through the loop.
- Nested Loops
o Start with inner loop. Set all other loops to minimum values.
o Conduct simple loop testing on inner loop.
o Work outwards.
o Continue until all loops tested.
- Concatenated Loops
o If independent loops, use simple loop testing.
o If dependent, treat as nested loops.
- Unstructured loops
o Don't test - redesign.

Control Structure Testing : Data Flow Testing

Data Flow Testing is a technique which is used effectively alongside Control Flow Testing. It is another type of white-box testing which looks at how data moves within a program. Data flow occurs when variables are declared and then accessed and changed as the program progresses.
A "definition-clear path" is a path which involves no changes of the variable being tested. For a statement with S as its statement number,

DEF(S) = {X| statement S contains a definition of X}
USE(S) = {X| statement S contains a use of X}

If statement S is an if or loop statement, its DEF set is left empty and its USE set is founded on the condition of statement S. The definition of a variable X at statement S is live at statement S’ if there exists a path from statement S to S’ which does not contain any condition of X.

A definition-use chain (or DU chain) of variable X is of the type [X,S,S’] where S and S’ are statement numbers, X is in DEF(S), USE(S’), and the definition of X in statement S is live at statement S’.

One basic data flow testing strategy is that each DU chain be covered at least once. Data flow testing strategies are helpful for choosing test paths of a program including nested if and loop statements.

Control Structure Testing : Condition testing

Condition testing is a test case design approach that exercises the logical conditions contained in a program module. Errors in conditions can be due to:
* Boolean operator error
* Boolean variable error
* Boolean parenthesis error
* Relational operator error
* Arithmetic expression error
The condition testing method concentrates on testing each condition in a program. The purpose of condition testing is to determine not only errors in the conditions of a program but also other errors in the program. A number of condition testing approaches have been identified.
Domain testing needs three and four tests to be produced for a relational expression. For a relational expression of the form
E1 < relational-operator > E2
Three tests are required the make the value of E1 greater than, equal to and less than E2,respectively.

Control Structure Testing : Branch Testing

Although basis path testing is simple and highly effective, it is not enough in itself. Next we consider variations on control structure testing that broaden testing coverage and improve the quality of white box testing. Control structure testing is a group of white-box testing methods.
* 1.0 Branch Testing
* 1.1 Condition Testing
* 1.2 Data Flow Testing
* 1.3 Loop Testing

Branch Testing : Branch Testing is a structural or white box technique, because it is conducted with reference to the code. A decision is an executable statement that may transfer control to another statement. It is also called Decision Testing. For every decision, each branch needs to be executed at least once. It ignores implicit paths that result from compound conditionals. It treats a compound conditional as a single statement.
- This example has two branches to be executed:
IF ( a equals b) THEN
statement 1
ELSE
statement 2
END IF
- This examples also has just two branches to be executed, despite the compound conditional:
IF ( a equals b AND c less than d ) THEN
statement 1
ELSE
statement 2
END IF
- This example has three branches to be executed:
IF ( a equals b) THEN
statement 1
ELSE
IF ( c equals d) THEN
statement 2
ELSE
statement 3
END IF
END IF
- Obvious decision statements are if, for, while, switch.
- Subtle decisions are return (boolean expression), ternary expressions, try-catch.

Web Engineering Process

Choosing a process model is based on the attributes of the software to be developed.
If immediacy and continuous evolution are the primary attributes of WebApp, a web engineering team might choose an agile process model. If a WebApp is to be developed over a longer time period, an incremental process model might be chosen.

Defining a Framework :
Any one of the agile process models can be applied successfully as a WebE process. Before we define a process framework for WebE, three things must be kept in mind :
- WebApps are often delivered incrementally.
- Changes will occur frequently.
- Timelines are short.

WebE Process Framework :
- Customer Communication : Within the WebE process, customer communication is characterized by :
* Business analysis : It defines the business/organizational context for the WebApp
* Formulation : It is a requirements gathering activity involving all stakeholders. The intent is to describe the problem that the WebApp is to solve.
- Planning : The “plan” consists of a task definition and a timeline schedule for the time period (usually measured in weeks) projected for the development of the WebApp increment.
- Modeling :
Analysis model — establishes a basis for design.
* Content Analysis
* Interaction Analysis
* Functional Analysis
* Configuration Analysis
Design model — represents the key WebApp elements.
* Content design
* Aesthetic design
* Architectural design
* Interface design
* Navigation design
* Component design
- Construction : WebE tools and technology are applied to construct the WebApp that has been modeled.
- Deployment : The WebApp is configured for its operational environment, delivered to end-users, and then an evaluation period commences.

WebApp Engineering Layers

The development of Web based systems and applications incorporate specialized process models, software engineering methods adapted to the characteristics of WebApp development, and a set of important enabling technologies. Process, methods, and technologies provide a layered approach to WebE that is conceptually identical to the software engineering layers :
- Process
WebE process models embrace the agile development philosophy that defines the following activities
* Embrace change.
* Encourages the creativity and independence of development staff and strong interaction with WebApp stakeholders.
* Builds systems using small development team
* Emphasizes evolutionary or incremental development using short development cycles.

- Methods
The WebE methods landscape encompasses a set of technical tasks that enable a Web engineer to understand, characterize, and then build a high-quality WebApp.

* Communication methods : It defines the approach used to facilitate communication between Web engineers and all other Web stakeholders.
* Requirements analysis methods : These methods provide a basis for understanding the content to be delivered by WebApp, the function to be provided for the end user, and modes of interaction that each class of user will require.
* Design methods : It encompasses a series of design techniques that address WebApp content, application and information architecture, interface design, and navigation structure.
* Testing methods : It incorporates formal technical reviews of both the content and design model and a wide array of testing techniques.

- Tools and Technology
These technologies encompasses a wide array of content description and modeling languages, browsers, multimedia tools, site authoring tools, database connectivity
tools, servers and server utilities, and site management and analysis tools.

Attributes of Web Based Systems

Web-based systems and applications deliver a complex array of content and functionality to a broad population of end-users. The following attributes are encountered in the vast majority of WebApps.

- Network Intensiveness.
- Concurrency.
- Unpredictable load.
- Performance.
- Availability.
- Data driven.
- Content sensitive.
- Continuous evolution.
- Immediacy.
- Security.
- Aesthetics.

The following application categories are most commonly encountered in WebE work :
- Informational : read-only content is provided with simple navigation and links.
- Download.
- Customizable.
- Interaction.
- User input.
- Transaction-oriented.
- Service-oriented.
- Portal.
- Database access.
- Data warehousing.

What are Client Server Applications ? A more detailed description

Client server applications are very suitable for the current web world. It is very easy to translate modern web applications into a client server model. For example, if you consider the usage of Yahoo mail that you access through your favorite browser, it is also a client server architecture, at multiple levels. If you consider the case of the Yahoo mail, your browser or mobile runs a client software that connects to a program running at the server which renders the web pages; then the web server itself acts as a client to a database running at the server farm which supplies the actual data that is returned back to the server program, from where it is returned to the client running at the browser.
If you consider the technology of the client server architecture, it is also referred to as a 2 tier architecture, with the 2 tiers being the client and the server. This is the most basic form of the client server architecture, and it can be expanded to go upto using multiple levels such as described in the Yahoo mail program explained above. Both the client and server softwares are normally considered as part of the same software, but they can be modified separately and yet the network keeps on working.
The client server model allows the setting up of such networks that can span across multiple locations, with the client software residing in one location, and the server application in another location. The advantage and simplicity of the client server architecture has made it the prominent architecture behind most modern business and non-business applications. In a mark of how important this model is, even the mainframes of the past have now started using a client server model.

Client Server Applications: The definition

What is Client Server Architecture ? What is some of the defining characteristics of Client Server Applications, especially since there is a buzz for the past many years about web applications, or a mixed breed (using applications such as Adobe AIR).
Client Server applications are literally define by the names used where one software application, at the client end (or at the user end) makes a service request to another software application that sits at the server (typically a machine with a much higher configuration). However, the separation between the client and server is logical, since both of them could exist on the same machine. There is a process to separate the work load of the application between the server application, and the client application. Client server applications are one of the central concepts behind network computing. Initially, the term was used to differentiate between the mainframe model or the Unix model where the entire work was done at the server, and the client was typically dumb, with no capability to do any processing.

Introduction to Web Engineering

The impact of Web-based systems and applications is arguably the single most significant event in the history of computing. As WebApps grow in importance,a disciplined WebE approach adapted from software engineering principles, concepts, process, and methods has begun to evolve.
WebApps are different from other categories of computer software. They are network intensive, content driven, and continuously evolving. The immediacy that drives their development, the overriding need for security in their operation, and the demand for aesthetic as well as functional content delivery are additional differentiating factors. Like other types of software, WebApps can be assessed using a variety of quality criteria that include usability, functionality, reliability, efficiency, maintainability, security, availability, scalability, and time to market.

WebE can be described in three layers - process, methods, and tools/technology. The WebE process adopts the agile development philosophy that emphasizes a "lean" engineering approach that leads to the incremental delivery of the system to be built. The generic process framework - communication, planning, modeling, construction, and deployment - is applicable to WebE. These framework activities are refined into a set of WebE tasks that are adapted to the needs of each project. A set of umbrella activities similar to those applied during software engineering work - SQA, SCM, project management - apply to all WebE projects.

Requirements Management

Requirements management involves communication between the project team members and stakeholders, and adjustment to requirements changes throughout the course of the project. To prevent one class of requirements from overriding another, constant communication among members of the development team is critical. For example, in software development for internal applications, the business has such strong needs that it may ignore user requirements, or believe that in creating use cases, the user requirements are being taken care of. The purpose of requirements management is to assure the organization documents, verifies and meets the needs and expectations of its customers and internal or external stakeholders.

Requirements traceability is concerned with documenting the life of a requirement. It should be possible to trace back to the origin of each requirement and every change made to the requirement should therefore be documented in order to achieve traceability. Even the use of the requirement after the implemented features have been deployed and used should be traceable.

The purpose of the Requirements Traceability Matrix is to help ensure the object of the requirements conforms to the requirements by associating each requirement with the object via the traceability matrix.
A traceability matrix is used to verify that all stated and derived requirements are allocated to system components and other deliverables.

- Features Traceability Table : It shows how requirements relate to important customer observable system/product features.
- Source Traceability Table : It identifies the source of each requirement.
- Dependency Traceability Table : It indicates how requirements are related to one another.
- Subsystem Traceability Table : it categorizes requirements by the subsystem that they govern.
- Interface Traceability Table : It shows how requirements relate to both internal and external system interfaces.

Requirements Engineering Tasks

Requirements Engineering :
* Provides a solid approach for addressing challenges in software project.
* Must be adapted to the needs of the: Process, project and product and the people doing the work.
* Begins during the communication activity and continues into the modeling activity.
* Helps software engineers to better understand the problem they will work to solve.

Requirements Engineering Tasks :
- Inception
* A task that defines the scope and nature of the problem to be solved.
* Software engineers ask context-free questions.
* Intent is to establish a basic understanding of the problem, the people who want a solution, nature of the solution that is desired and the effectiveness of preliminary communication and collaboration between the customer and the developer.

- Elicitation
Ask the customer, the users and others about the objectives of the system, what is to be accomplished, how the system of product fits into the needs of the business and finally, how the system or product is to be used on a day-to-day basis.
Why Elicitation is Difficult?
* Problems of scope.
* Problems of understanding.
* Problems of volatility.

- Elaboration
* Basic requirements (obtained from the customer during inception and elicitation) are refined and modified.
* Focuses on developing a refined technical model of software functions, features and constraints..
* Driven by the creation and refinement of user scenarios.
* End-result: analysis model that defines the informational, functional and behavioral domain of the problem.

- Negotiation
* There’s no winner and loser in an effective negotiation.
* Customers usually ask for more rather than what can be achieved.
* Some proposed conflicting requirements.
* The requirements engineer must reconcile these conflicts through a process of negotiation.

- Specification
* It can be written document, a set of graphical models, a formal mathematical model,a collection of usage scenarios,a prototype,or any combination of these.
* It is the final work product produced by the requirements engineer.
* It serves as the foundation for subsequent software engineering activities.
* It describes the function and performance of a computer-based system and the constraints that will govern its development.

- Validation
* Work products produced are assessed for quality in this step.
* A task which examines the specification to ensure that all software requirements have been stated unambiguously.
* That inconsistencies, omissions and errors have been detected and corrected.
* That work products conform to the standards established for the process, project and the product.

Types Of Requirements

Requirements are categorized in several ways. The following are common categorizations of requirements that relate to technical management.

- Customer Requirements
Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS). The customers are those that perform the eight primary functions of systems engineering, with special emphasis on the operator as the key customer.
* Operational distribution or deployment: Where will the system be used?
* Mission profile or scenario: How will the system accomplish its mission objective?
* Performance and related parameters: What are the critical system parameters to accomplish the mission?
* Utilization environments: How are the various system components to be used?
* Effectiveness requirements: How effective or efficient must the system be in performing its mission?
* Operational life cycle: How long will the system be in use by the user?
* Environment: What environments will the system be expected to operate in an effective manner?

- Functional Requirements
Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the toplevel functions for functional analysis.

- Non-functional Requirements
Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors.

- 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.

- Design Requirements
The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals.

- Derived Requirements
Requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight.

- Allocated Requirements
A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items.

Overview of Requirements Engineering

Software requirements engineering is the process of determining what is to be produced in a software system. In developing a complex software system, the requirements engineering process has the widely recognized goal of determining the needs for, and the intended external behavior, of a system design. This process is regarded as one of the most important parts of building a software system.
Requirements engineering is an important aspect of any software project, and is a general term used to encompass all the activities related to requirements. The five specific steps in software requirements engineering are:

* Requirements inception
* Requirements elicitation
* Requirements analysis
* Requirements specification
* Requirements validation

Although they seem to be separate tasks, these four processes cannot be strictly separated and performed sequentially. All four are performed repeatedly because the needs are often impossible to realize until after a system is built. Even when requirements are stated initially, it is likely they will change at least once during development, and it is very likely they will change immediately after development.