Lecture 01 RE Fundamentals

Requirements Engineering fundamentalsSWENG 580: advanced software engineeringWhat is requirements engineering ? What are requirements? How are requirements specified?

Engineering Division, The Pennsylvania State University*SWENG 580: Advanced Software Engineering

What is requirements engineering?Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families. (Zave, 1997)


real world goalsMotivation for development of the software systemWhy are we building the system?What system are we building?


precise specificationProvide the basis forAnalyzing the requirementsValidating that these requirements are what stakeholders wantDefining what the designers have to buildVerifying that the designers have built the right system


evolution over time and across software familiesEmphasizes the reality ofA changing worldThe need to reuse partial specifications


Core RE activitiesPlanning and Eliciting requirements.Who is the target for elicitation?What techniques are used for elicitation?Are requirements feasible?How to identify and manage risk?Modeling and Analyzing requirements.How formal and abstract should be the model?How expressive is the model? Does it support multiple different viewpoints?What are the techniques for modeling enterprises, information structures, and behavior?How do you model quality requirements?Communicating and Agreeing requirements.How are requirements documented?How do you negotiate and prioritize requirements?How do you review and inspect requirements?How do you validate requirements?Realizing and Evolving requirementsHow do you manage change?How do you manage inconsistency?What about traceability?.


RE draws from diverse disciplinesComputer sciencelogic formalisms allow analysis of specificationsSystems engineeringcharacterizing systemsidentifying system boundariesAnd


PhilosophyEpistemology understanding beliefs of stakeholdersPhenomenology what is observable in the worldOntology what can be agreed on as objectively true


Cognitive psychologyProvides an understanding of the difficulties people may have in describing their needs.Domain experts utilize subconscious knowledge that they cannot articulate leading to a mismatch between their response to questions and their actual behavior.


AnthropologyObserving human activities helps in understanding how computer systems may help or hinder those activities.Ethnomethodology has been used to develop observational techniques for analyzing team-working (also termed ethnography)


SociologyUnderstanding the political and cultural changes caused by technology.Introduction of a computer system can change many things:An organizations way of workingAn organizations structureCommunication pathsEven the original needs that it was built to satisfyMust ensure the process doesnt become politicized possibly by involving those most affected by the system


LinguisticsRE is about communication.Ambiguity and misunderstanding is easy when natural language is used to express requirements.


What is a requirement?Can range from a high-level, abstract statement of a service or constraint to a detailed, formal specification.Why?Requirements may be basis for a bid so must be open to interpretation.Requirements may be part of the contract itself so must be defined in detail.


Requirement abstractionIf a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization's needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system. (Davis, 1993)


Requirement separates the problem from the solutionA separate problem description is useful as it can serve as a basis for discussion with stakeholders to see if it corresponds to their needs, evaluating design choices and generating test casesFigures Steve Easterbrook


But this is not a sequential processRequirements engineering is iterative; a complete problem specification does not have to exist before the solutionIn fact, the problem statement is never fixed and change is inevitablePerfecting a problem statement may not be cost effective either


Requirements classificationTo cope with this duality we can classify requirements in terms of their level of abstraction.Sommerville (2005) suggests:User requirementsSystem requirementsSoftware design specifications


User requirementsAbstract statements written in natural language with accompanying informal diagrams. Specify what services (user functionality) the system is expected to provide and any constraints.


System requirementsDetailed descriptions of the services and constraints.Should be structured and precise.Acts as contract between client and contractor.Sometimes referred to as functional specification or technical annex.Derived from analysis of the user requirements.


Software design specificationsThe analysis and design documentation used as basis for implementation by developers.Derived from analysis of the system specification


ExampleUser requirement 1.The software must allow a user to access, and subsequently bet on individual sporting eventsSystem Requirement 1.1 The user should be presented with the available sporting events 1.2 Facilities should be provided to allow the user to search the available events based upon the sport, the date/time or by competitor. 1.3 The software should allow users to select one or more events from the selection. 1.4 The selected events should be presented along with the current odds for each event and outcome. 1.5 The software should allow the user to place a bet on any of those events in the selection. 1.6 The software should record that bet, updating the users account.


Another classificationFunctional requirementsNon-functional requirementsDomain requirements


Functional requirementsThe services the system should provide.How it will react to inputs.Sometimes state what the system should not do.Can be high-level and general (user requirements) or detailed, expressing inputs, outputs, exceptions, etc. (system requirements)


Non-functional requirementsRequirement imposed by the environment in which the system is to exist.This could mean timing constraints, quality properties, standard adherence, programming languages to be used


Non-functional requirement types


Goals versus requirementsSome NFRs are difficult to define precisely making them difficult to verify.Should distinguish goals from NFRs Goal a general intention of a stakeholder The system should be easy to use by experienced operators

Verifiable NFR statement using some objective measure. Experienced operators shall be able to use all the system functions after 2 hours of training


Domain requirementsDerived from the application domain.May be: New functional requirements.Constraints on existing functional requirements.Specify how particular computations must be performed.


Train protection systemThe deceleration of the train shall be computed as:Dtrain = Dcontrol + Dgradient

where Dgradient is 9.81ms2 * compensated gradient/alpha and where the values of 9.81ms2 /alpha are known for different types of train.


Eh!The example highlights an important issue with domain requirements.They are often expressed by domain experts using domain-specific terminology.They are used by software engineers unfamiliar with the intricacies of the domain.Additionally, domain experts often leave out information from a requirement as they understand the area so well.


User requirementsDescribe functional and non-functional requirements as they pertain to externally visible behavior in a form understandable by clients and/or system users.Use natural language, tables and simple intuitive diagrams.


Problems with natural languageLack of clarity Precision is difficult without making the document difficult to readRequirements confusionFunctional and non-functional requirements tend to be mixed-upRequirements amalgamationSeveral different requirements may be expressed together

Hence the need for linguistics knowledge!


Example: database requirementThe database shall support the generation and control of configuration objects; that is, objects which are themselves groupings of other objects in the database. The configuration control facilities shall allow access to the objects in a version group by the use of an incomplete name.

Fault: Includes both conceptual and detailed informationDescribes the concept of configuration control facilitiesIncludes the detail that objects may be accessed using an incomplete name


Example: editor grid requirement2.6 Grid facilities To assist in the positioning of entities on a diagram, the user may turn on a grid in either centimeters or inches, via an option on the control panel. Initially, the grid is off. The grid may be turned on and off at any time during an editing session and can be toggled between inches and centimeters at any time. A grid option will be provided on the reduce-to-fit view but the number of grid lines shown will be reduced to avoid filling the smaller diagram with grid lines.

Fault: Grid requirement mixes three different kinds of requirementConceptual, functional requirement states that the editing system should provide a grid and presents the rationale.Non-functional requirement giving detailed information about grid units.Non-functional UI requirement which defines how that grid is switched on and off by user.


Guidelines for writing requirementsInvent a standard format and use it for all requirementsUse language in a consistent way. Use shall for mandatory requirements,Use should for desirable requirementsUse text highlighting to identify key parts of the requirementAvoid the use of technical language


Example: editor grid requirement2.6 Grid facilities

2.6.1 The editor shall provide a grid facility where a matrix of horizontal and vertical lines provide a background to the editor window. This grid shall be a passive grid where the alignment of entities is the user's responsibility.Rationale: A grid helps the user to create a tidy diagram with well-spaced entities. Although an active grid, where entities 'snap-to' grid lines can be useful, the positioning is imprecise. The user is the best person to decide where entities should be positioned.


Example: editor node requirement3.5.1 Adding nodes to a design3.5.1.1The editor shall provide a facility for users to add nodes of a specified type to their design. 3.5.1.2The sequence of actions to add a node should be as follows:1. The user should select the type of node to be added. 2. The user should move the cursor to the approximate node position in the diagram and indicate that the node symbol should be added at that point.3. The user should then drag the node symbol to its final position.Rationale: The user is the best person to decide where to position a node on the diagram. This approach gives the user direct control over node type selection and positioning.


System requirementsMore detailed specifications of user requirementsServe as a basis for designing the systemMay be used as part of the system contractSystem requirements may be expressed using system models (first iteration of analysis models)


More problems with NL specification AmbiguityThe readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficultOver-flexibilityThe same thing may be said in a number of different ways in the specificationLack of modularizationNL structures are inadequate to structure system requirements


Alternatives to natural language

Notation

Description

Structured natural language

This approach depends on defining standard forms or templates to express the requirements specification.

Design description languages

This approach uses a language like a programming language but with more abstract features to specify the requirements by defining an operational model of the system.

Graphical notations

A graphical language, supplemented by text annotations is used to define the functional requirements for the system. An early example of such a graphical language was SADT (Schoman and Ross, 1977). More recently, use-case descriptions (Jacobsen, Christerson et al., 1993) have been used.

Mathematical specifications

These are notations based on mathematical concepts such as finite-state machines or sets. These unambiguous specifications reduce the arguments between customer and contractor about system functionality. However, most customers dont understand formal specifications and are reluctant to accept it as a system contract.


Structured language specificationA limited form of natural language may be used to express requirementsThis removes some of the problems resulting from ambiguity and flexibility and imposes a degree of uniformity on a specificationOften best supported using a forms-based approach


Form-based specificationInclude the following information:1. Definition of the function or entity2. Description of inputs and where they come from3. Description of outputs and where they go to4. Indication of other entities required5. Pre- and post-conditions (if appropriate)6. The side effects (if any)


Example: form-based node specificationFunctionAdd nodeDescriptionAdds a node to an existing design. The user selects thetype of node, and its position. When added to thedesign, the node becomes the current selection. The user chooses the node position by moving the cursor tothe area where the node is added.InputsNode type, Node position, Design identifierOutputsDesign identifierDestinationThe design database. The design is committed to thedatabase on completion of the operation.RequiresDesign graph rooted at input design identifierPre-conditionThe design is open and displayed on the user's screenPost-conditionThe design is unchanged apart from the addition of anode ofthe specified type at the given positionSide-effectsNone


PDL-based requirements definitionRequirements may be defined operationally using a language like a programming language but with more flexibility of expressionMost appropriate in two situationsWhere an operation is specified as a sequence of actions and the order is importantWhen hardware and software interfaces have to be specifiedDisadvantages areThe PDL may not be sufficiently expressive to define domain conceptsThe specification will be taken as a design rather than a specificationNotation is only understandable to people with programming language knowledge


Part of ATM specification

class ATM {

// declarations here

public static void main (String args[]) throws InvalidCard {

try {

thisCard.read () ; // may throw InvalidCard exception

pin = KeyPad.readPin () ; attempts = 1 ;

while ( !thisCard.pin.equals (pin) & attempts < 4 )

{pin = KeyPad.readPin () ; attempts = attempts + 1 ;

}

if (!thisCard.pin.equals (pin))

throw new InvalidCard ("Bad PIN");

thisBalance = thisCard.getBalance () ;

do { Screen.prompt (" Please select a service ") ;

service = Screen.touchKey () ;

switch (service) {

case Services.withdrawalWithReceipt:

receiptRequired = true ;


Interface specificationMost systems must operate with other systems and the operating interfaces must be specified as part of the requirementsThree types of interface may have to be definedProcedural interfacesData structures that are exchangedData representationsFormal notations are an effective technique for interface specification


PDL interface specificationinterface PrintServer {// defines:an abstract printer server// requires:interface Printer, interface PrintDoc// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrintervoid initialize ( Printer p ) ;void print ( Printer p, PrintDoc d ) ;void displayPrintQueue ( Printer p ) ;void cancelPrintJob (Printer p, PrintDoc d) ;void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;} //PrintServer


The requirements documentThe requirements document is the official statement of what is required of the system developersShould include both a definition and a specification of requirementsIt is NOT a design document. As far as possible, it should be a set of WHAT the system should do rather than HOW it should do it


Users of requirements document


Requirements for a requirements documentSpecify external system behaviourSpecify implementation constraintsEasy to changeServe as reference tool for maintenanceRecord forethought about the life cycle of the system i.e. predict changesCharacterize responses to unexpected events


Key pointsRequirements set out what the system should do and define constraints on its operation and implementationFunctional requirements set out services the system should provideNon-functional requirements constrain the system being developed or the development processUser requirements are high-level statements of what the system should doUser requirements should be written in natural language, tables and diagramsSystem requirements are intended to communicate the functions that the system should provideSystem requirements may be written in structured natural language, a PDL or in a formal languageA software requirements document is an agreed statement of the system requirements


ReferencesA. Davis, Software Requirements: Objects, Functions and States, Second Edition, Upper Saddle River, NJ: Prentice-Hall, 1993.B. Nuseibeh and S. Easterbrook,Requirements Engineering: A Roadmap, Proceedings of the International Conference on Software Engineering, Limerick, Ireland, June 2000, pp. 35 46.I. Sommerville, Software Engineering, 7th ed., Boston, MA: Addison-Wesley, 2005.P. Zave, Classification of Research Efforts in Requirements Engineering, ACM Computing Surveys, 29(4), pp 315 321.

**

Documents

Lecture 01 RE Fundamentals