Software Development Processes Course: Research Paper

CSci 713

Script for Requirements Engineering

<< Alex, I would like you to read the material before Slide 1: without opening Powerpoint to the slides. Instead, I hope you will be willing to sow your face and introduce yourself during that time. I think students would be much happier to be able to associate a name and a face with the presentations. Thank you!!>>

One huge caveat before we begin. The range and variety of modern software development projects is very wide. Some projects are single developer, informal efforts with perhaps the developer or a few co-workers as the only intended users. At the other extreme are projects with more than a1,000 developers in many locations throughout the world. There are projects at every point over this entire range.

Some projects result in a page r less of code. Others result in tens of millions of lines of code in many programming and scripting languages. Again, there are projects at every point in between.

Some projects are finished in just a few hours. Others can take more than five years. Again, there are projects at every intermediate point also.

The range of product types is vast also. Some products have only a ingle user and run on a single computer, perhaps in a single process. Other products run on servers throughout the world and support tns of thousands or more simultaneous users.

Clearly, with the huge variety of projects and products over several dimensions, no coherent presentation can speak to all of them. This presentation is targeted towards larger projects produced by one or more teams of developers over one to five years. Smaller projects can ignore some or all of the practices detailed here. Unfortunately, smaller projects tend to ignore too many of these practices, resulting in much more rework and reduced prospects for success.

Slide 1:

Onc a software development project has received authorization, a tentative schedule, and a team of developers, the project proposal must be greatly expanded with an extensive set of requirements. The process of developing this set of requirements is called Requirements Engineering.

There are three targets for the initial requirements engineering, depending on the development lifecycle and methodology being used on this project. If a sequential lifecycle such as Waterfall is used, every reasonable effort is made to produce a complete, accurate set of requirements. Developers and most business stakeholders know that the requirements almost certainly will require revision as the project proceeds, but the more complete and accurate the initial set of requirements, the less often expensive responses to revisions must be made.

The second possible target is to spend less effort than with the first target, but try to produce a tentative set of requirements for the entire product. Many iterative lifecycle methodologies adopt this target. This target allows better scheduling of the overall project, and better development of a product architecture than the third possible target.

The third possible target is use din Agile and Lean development methodologies. Just enough requirements for the first release are produced. This target requires the least effort initially, but also results in a greater likelihood that the product architecture will need extensive revision during development.

If a sequential development is attempted, the requirements production is done once at the beginning of the development lifecycle. Small scale efforts may be needed during development to revise the requirements if and when significant changes occur

If an iterative development is attempted, requirements production is done at the start of development and at the start of each iteration.

In this course, we provide an overview of Requirements Engineering. Another course, CSci 715, spends an entire semester going much deeper into Requirements Engineering.

Slide 2:

There are different types of requirements. Functional requirements concern specific features of interest to users and/or business stakeholders. One trend over the last thirty years gas veeb for production of functional requirements to involve potential product users to a much greater degree. Functional requirements have an advantage that they usually are easier for users, business stakeholders, and developers to understand to mean the same thing. Other requirements are much more likely to result in miscommunication among these groups. Another advantage of functional requirements is that identification of how they affect the product is usually straightforward. In most cases, a functional requirement has a very local impact on only a small part of the product. For example, consider the functional requirement: A user should be able to upload a new description at any time after the sale item has been created. This requirement likely would be implemented in one or two methods within a single class.

Nonfunctional requirements are more difficult to identify and to get the three groups to form the same meaning for the words written. Further, the impact of a nonfunctional requirement may be difficult to discern and diffuse throughout the product. For example, consider the requirement that all responses to user requests must take no more than 2 seconds to complete. Determining whether or not this requirement is met cannot be definitive until the entire product is available and tested under actual production conditions. Some potential users and the developers could disagree on whether or not this requirement is met. Developers may ignore the background updating of a database that occurs. The user might be upset because the data is not updated in time for another application to retrieve the latest value.

Quality attributes are requirements that affect the quality of the product. These requirements are in such areas as product performance, reliability, security, precision, privacy, environmental impact, and so on. This type of requirement often is the most difficult to discover, but also the most important in determining eventual user satisfaction.

Constraints on the product are such requirements as to work with specific releases of specific database management systems or operating systems. This classification includes the need for the product to work in the Cloud or as a software as a service.

Constraints on the development process might include the need to have a working, competitive product by a specific date. This category includes a requirement to implement in a given language or with a given set of tools and computers.

Business requirements are those imposed either by Legal or Accounting requirements, or by other business concerns. For example, the company may demand that the product record specified user activity for use in targeting paid ads.

Marketing requirements include the possible need for specific “wow” features to address the competition. There might be additional marketing requirements based on what the competition provides, or is rumored to provide in the future.

Slide 3:

Requirements are described in any of several ways,some textual, and others graphical. Thisslide presents three functional requirements for different applications. Each is expressed as a single sentence requesting a single capability be available to users. Each needs various terms such as student grades or weighted assignments to be defined elsewhere. These terms are defined in the last part of the Requirements Specification called the Glossary. Since some methodologies do not use a formal requirements specification document, the definitions might instead appear in a standalone document, usually online, called the Data Dictionary. Developers have found it is better to define these terms separately rather than bogging down each requirement with a set of needed definitions.

Slide 4:

This slide provides three example non-functional requirements as single sentences. The first example is a performance requirement. That requirement might affect many other functional and no n-functional requirements for this product. In fact, even experienced developers usually are not correct in figuring out which requirements might be affected by a quality attribute such as performance or security. Some important dependencies might not be discovered until the product has been in operation for considerable time.

The second example requirement is another quality attribute, this time related to providing full access to disabled users. Developers and business stakeholders need to understand that potential users who are disabled In some way make up a significant percentage of potential users. This percentage is growing as the world’s population, especially the developed world, ages. There is a trend in the developed world for increasing numbers of employees to be older, sometimes into their 80’s. They are more likely to have disabilities than younger employee.

The third sample requirement is another quality attribute. This requirement is in the area of reliability.

Slide 5:

There are many ways to describe requirements, some textual and some graphical. The textual forms usually involve either imperative sentences such as the examples on the previous two slides, or using an explicit template such as:

For <class of users or set of business stakeholders> the product must support <operation> on <explicit set of data> producing <specific result> with <list of explicit side effects>.

Using this template, a requirement might be:

For administrative users the product must support tracing user modifications to inventory data with the saving of these traces in the administrative database.

Various terms within this requirement would need definitions in the Glossary or the Data Dictionary including administrative user, user, inventory data, and administrative database.

User story and, especially, use case provide other approaches to describing requirements. These approaches tend to be used in Agile and Lean methodologies. The next several slides will describe these two, more recent, approaches.

Slide 6:

The user story starts with a name which must be unique among all the specified requirements. Then, the requirement is described in one to three sentences. The main difference between user stories and the previous approaches is that user stories are intended to be written by potential users and business stakeholders. The earlier requirements descriptive techniques were written by developers with indirect input from users and business stakeholders through surveys or interviews.

Just as with other means of describing requirements, the user story contains several nouns, and sometimes verbs, which must be defined elsewhere, Elsewhere is either the Glossary portion of the Requirements Specification document or the standalone Data Dictionary.

Slide 7:

Use cases usually incorporate what would be several requirements in the other forms of description. The use case presents a complete dialog between a user and the product. Uses cases are based on the classic stimulus-response model of Psychology. The user makes a request (stimulus) of the product. The product responds in some way. Then the user makes another request. The back-and-forth continues until the interaction is complete.

As you can see from the example, the user stimuli are the odd statements. The product responses are the even statements. Generally, the use case begins with the user starting the product and ends with the product ceasing to interact with this user. However, since many products tend to interact with a user through multiple transactions before the user leaves the product, most uses of use cases do not require that each use case represent an entire session for one user. Instead, there are one or more use cases for starting the relationship between a user and the product, and one or more for terminating the relationship.

Use cases do not describe user interfaces. The use case describes the user providing certain information to the product and the product providing certain information to the user. The format of that information and the way in which the user and product access that information is not described.

Use cases treat the user and the product as black boxes. Nothing is described in how the product does its work. Nothing is described as to how the user decides on the specific input to provide.

Individual use cases do not contain conditional statements such as if-then-else. Instead, use cases are organized into families. The primary use case in a family is the one where everything succeeds (login is successful, the database is available, etc.). Secondary use cases in the same family show alternatives. Each secondary use case in a family branches off from the primary or another secondary use case when a decision is made differently. Where a secondary use case branches off from another use case can be shown in the base use case by placing the name of the secondary use case in the left margin of the base use case at the point of divergence.

Sometimes a dialog includes repetition of a sequence of stimulus-response pairs. This can be shown by prefixing the repetition with the keyword LOOP and ending the repetition with the keyword END. Either the LOOP or the END keyword can be followed by the reason for ending the repetition.

Slide 8:

A typical set of requirements contains hundred, thousands, or even tens of thousands of individual requirements. No human can comprehend this complex set without it being organized in some effective way. The top-level organization by type of requirement is not sufficient. Within each type of requirement such as Functional, individual requirements are organized into features and the features organized by another criterion. This other criterion depends on the characteristics of the product. For example, the criterion might be different types of user. Another possible criterion is where that feature will be supported (client or server, for example). Another possible criterion is the data collection upon which that feature might act. For example, an application that determines whether or not an applicant qualifies for a specific loan might organize features by those that affect information on the user’s income,, information on the lender, information on loan history, etc. A single feature might be repeated in more than one category.

Slide 9:

Requirement engineering consists of six activities. The first five activities are done in sequence, either once at the beginning of the project, or once at the beginning and then once each iteration. The sixth activity is done throughout the entire project.

Elicitation is the collecting of potential requirements.

Analysis and negotiation is the activity that checks that the candidate requirements have certain desirable properties such as being unambiguous. Then the requirements are estimated by the developers. Finally, this activity includes negotiations with the business stakeholders to determine tentatively which requirements will be included in the current release or iteration.

System modeling is done by the developers to assist in their determining an architectural design for this product.

Specification is the organization and documentation of the active requirements. Documentation might be ina requirements specification document or in several backlogs. These have been explained in the earlier presentations on development methodologies.

Validation ensures that the requirements and their documentation satisfy certain properties. These properties will be presented on a future slide.

Management ensures that the requirements are as current and accurate as possible. This activity also tracks the completion of specific requirements. The amount of and rate of progress in satisfying requirements is measured and monitored every work day. Responses to any deviations from expected results must be effective.

The following slides describe one or a few methods among the many possible for doing each of these activities. CSci 715 spends an entire semester going into much more depth.

Slide 10:

Elicitation is the activity of collecting as many candidate requirements as possible. Elicitation involves as many business stakeholders and developers as possible.

Rapid Application Development (RAD) is a frequently used method. RAD consists of one or two days of meetings at a location away from the business. As many business stakeholders and developers as possible get together for a morning meeting and an afternoon meeting each day to develop as many requirements as possible. A professional moderator is hired to conduct the meetings. There are at least two people recording the conversation results for later reference. The recorders do not participate in the actual discussions. Participants are expected to carry on informal offline discussions during the frequent breaks and between meetings to wor out disagreements and provide clarifications. However, only what happens in the formal meetings counts. The developers participate to present the feasibility of proposed requirements and to get clarifications as to what a proposed requirement means to the business stakeholder who presents it.

Other approaches are less one-shot. Two developers can interview a single business stakeholder. The interview should have three parts: a brief social interaction of perhaps five minutes; a question and answer session of about forty minutes, and a brief closing social interaction of, perhaps, five minutes. The total interview should not be longer than one hour. One developer takes notes while the other developer asks the questions.

There are two types of interviews. A structured interview consists of ten to twenty prepared questions with limited opportunities for follow-up. An open-ended interview has only five or six prepared questions with ample opportunity to request clarification or bring up doubts.

The developers attempt to interview all relevant business stakeholders. These interviews are scheduled. They occur in the stakeholder’s office or a nearby conference room.

Following an interview, the developers involved write up their conclusions including any proposed requirements. This report is sent to the interviewee for revision and approval.

If the set of potential users of a product is large and/or geographically scattered, the developers might use a questionnaire or survey to elicit potential requirements from a sample of potential users. These instruments usually result in about a five percent response rate unless efforts are made to remind potential participants or to offer a desired reward. The most commonly offered rewards are t-shirts with the company logo, or entry in a drawing for a prize. These efforts generally bring the response rate up to about twelve to fifteen percent.

Slide 11:

Once a large set of potential requirements have been gathered using one or more of these techniques, the analysis phase begins. Each potential requirement is evaluated to determine if it has several necessary properties. The first such property is not being ambiguous. The developers try to evaluate if the requirement has the same meaning to all of them and to the relevant stakeholders. The second property is completeness. Does the requirement and the associated definitions in either the Glossary or the Data Dictionary fully describe what the relevant business stakeholders need? Determination of these two properties benefits greatly from business stakeholder involvement. When developers must decide upon these properties on their own, they often make mistakes.

The third property is one the developers can determine without business stakeholder involvement. This property is the feasibility of satisfying this requirement. Can this requirement be satisfied within all known constraints with an acceptable amount of effort?

The potential requirements that are determined to have all three properties move onto the next phase of requirements engineering. The potential requirements that fail either of the first two properties are returned to the originating stakeholders for further clarification. If that clarification is received within a few business days, the requirement is reevaluated for the three properties.

Slide 12:

The Modeling phase tries to understand the large set of requirements by using graphical diagrams to show relationships among different requirements or features. There are many diagrams that might be used. We will consider just two which are part of the Unified Modeling Language. UML consists of fourteen type s of diagrams and a constraint programming language to extend those diagrams. UML is very frequently used in almost every aspect of software development and maintenance.

The Use Case Diagram is defined to show relationships among various use cases and between use cases and the actors that are involved. An actor is an entity such as a person, another application, or a device separate from the product, but with which the product interacts to implement one or more use cases.

While the Use Case Diagram is defined to involve use cases, the actual internals of a use case are not shown in this diagram. Only the name of the use case or use case family is the given. Hence, the use case diagram may be used to show relationships among user stories or features or subsystems or natural language requirements just as well.

Each Use Case Diagram should be restricted to no more than about a dozen use cases (or stories or features or subsystems or requirements). . Otherwise, the diagram becomes too cluttered and may actually retard communication rather than enhance it. Multiple diagrams may be used to cover all of the requirements units of interest.

The Class Diagram is defined in terms of individual classes or modules and their relationships. Here again, it has been drafted for use in showing relationships among requirements or user stories or use cases or subsystems.

The Class Diagram should be limited in scope just as the Use Case Diagram and for the same reason. Multiple class diagrams may be used to cover all the requirement units of interest.

The extensions to these diagrams have not been standardized. Different development teams use them or other diagrams indifferent ways. System modeling tries to identify relationships, especially dependencies which could be important to the rest of the development process.

The next set of slides present these two diagrams with one way to adjust them to be effective in Requirements Engineering. Following those presentations, we will return to describing the phases of Requirements Engineering.

Slide 13:

In the use case diagram, each actor is identified by a stick figure in either the left margin or the right margin of the diagram. Each stick figure has the name of its role typed under the figure. If the same name appears beneath more than one figure, those stick figures represent the same actor. The actor is repeated solely to make the diagram less cluttered.

In the center of the diagram are the list of use cases or use case families, each presented in a single oval. Solid lines connect each use case oval to the actors involved in that use case.

There are two relationships among use cases shown by dotted lines with arrow heads. One relationship is contains which indicates that the containing use case generalizes the contained use case. The contained use case is the one with the arrow head. The second relationship is uses which indicates that the using case calls the used case as a subroutine. The used case has the arrow head.

How can developers extend this diagram to be useful in Systems Modeling? The actors can remain unchanged. Whichever requirements unit (user stories, use cases, use case families, features, subsystems, individual requirements) we want to consider appears in the ovals. The solid lines linking actors to the chosen requirements unit can remain unchanged.

What other relationships among requirements units might we want to show? Consider the following relationships:

• Depends upon: the initial requirement unit cannot be satisfied until the related requirements units are satisfied.

• Uses the same resource: this set of requirements units all use the same resource whether data or another application or a device. There are two subsets of this relationship: exclusive in which only one requirements unit may use the resource at a time, and shared in which multiple requirements units can use the resource at the same time.

• Co-located: the satisfaction of these requirements units must be located on the same device or in the same process.

The first relationship is asymmetric. We will use the solid line with an arrow head on one end to indicate this relationship. The arrow head will appear at the requirements unit upon which the initial requirements unit depends.

The other two relationships are symmetric. They will be shown by dotted lines linking the units. Alternatively, a rectangle could be drawn around the set of units. In either situation, the relationship should be labeled on the lines or above the rectangle. For example, a relationship could be labeled co-located in public cloud.

Slide 14:

This slide shows a use case diagram for a design. You should try to modify this version to show a possible set of requirements for the same application.

<<Pause for 20 seconds >>

Slide 15:

The Class Diagram probably is the most often extended diagram in UML. Originally, this diagram was defined to describe the classes and their relationships during Software Design.

There are two basic forms of the Class Diagram: preliminary, and full. In the preliminary diagram, each class is represented by a rectangle containing the name of the class. Solid lines are drawn between these rectangles to represent any of the following relationships:

• A method in the originating class calls a method in the receiving class. The direction of the call is indicated by an arrow head. The line is annotated with the signature of the method call followed bya the type of the return value.

• This class contains a reference to one or more members of the other class. The arrow head is placed on the contained class’s end. The link is annotated with the name of the reference. The multiplicity of each end of the link appears as a number over the link at that end. For example, if one end has a 3 and the other end has a 1, that means each class element at the 1 end has exactly three references to elements of the other class and each element of the other class is referenced by exactly one element of the other class. We will see more options for this multiplicity when we present Design.

• This class inherits from that class. The parent class has an open arrow head at its end of the link.

In the full version, each class description is expanded into three parts separated by horizontal lines. The top third shows the class name. The middle third shows the class and element data of this class, Each item kn this third has a visibility symbol, a name, and a datatype. The bottom third shows the class and element methods of this class. Each has a visibility, a name, and a signature. The visibility symbols will be explained when we revisit the class diagram in the Design presentation.

How do we adapt this diagram for use with requirements? We will use only the preliminary form. The same three relationships:

• Depends upon

• Uses the same resource

• Co-located

may be shown in the same ways.

Slide 16:

This slide shows a Clas Diagram for a design. You should try to modify it to describe requirements for the same application.

<<Pause for twenty seconds >>

Slide 17:

There are other ways to use a Class Diagram to model requirements. This slide and the next show two other approaches. On this slide, a method for showing which major user data each requirement unit accesses is given.

Slide 18:

This slide shows a method which is simpler and more flexible for showing the relationships among different requirements. Some developers might wish to employ both this method and the method on the previous slide since each shows different relationships that could be valuable in understanding how the requirements interact.

Developers also might find value in doing different diagrams with the same approach, but different levels of requirements unit. Other combinations of approaches could be useful as well. For example, developers could start with identifying co-located requirements units. Then for each set of requirements units which is co-located, the developers could use the data approach of the previous slide to suggest where different user data should be located. Your imagination or development experience probably can uncover other valuable combinations.

<<Pause for 5 seconds >>

Slide 19:

The Waterfall development process mandates use of a Formal Requirements Specification(SRS) document. In practice, many development projects, regardless of the label placed on the process, actually use some form of SRS. Even the various backlogs used in Agile and Lean processes often contain at least some of the fields of an SRS. Therefore, the next several slides discuss the Software Requirements Specification.

Note that the actual requirements in the SRS may be in any format including natural language or user stories or use cases.

The SRS has several goals. For the most part, these goals are shared by the various backlogs.

The first goal is to be a place where the current requirements for this project may be found. The current requirements should be accessible by the developers and any concerned business stakeholder at any time throughout the project.

The second goal is to serve as the basis for reviews. Agile and non-Agile projects alike review the current requirements at specified times throughout the project. The amount and speed of satisfying these requirements is the major determiner of if and when adjustments in the development process are desirable.

The third goal is to provide a basis for product design. All projects do architectural design in some form. The architecture comes from the requirements. The test-driven design done by Agile projects and the requirements driven design done by other projects both originate in requirements.

The fourth goal is to serve as a basis for system tests and acceptance tests. System tests are from the developers’ perspective. Acceptance tests are from the perspectives of business stakeholders, and then users. These groups base their tests on their understanding of the product’s requirements.

The fifth goal is to improve communication among the various groups concerned about the developing product. The most common reason for project failure is miscommunication. The requirements are the primary shared medium among developers, potential users, and business stakeholders. Some Agile methodologies such as SCRUM consider working code to be more important, but the groups other than the developers value working code to the extent the code satisfies their understanding of product requirements.

The sixth goa reiterates this point by emphasizing the importance of requirements as the basis for all communication between developers and business stakeholders. At least until the product is released to users, the business stakeholders are the ones who determine whether or not the project proceeds. Business stakeholders base their decisions about the product on their understanding of how well the product is satisfying the functional and quality requirements together with how well the project is meeting its requirements such as schedule.

The seventh goal is to support effective tracking. Progress during development is measured by how well subsequent phases of development after the first five phases of requirements engineering satisfy current requirements. Remember that the sixth phase, management, occurs throughout the project. We need to track individual requirements satisfaction through the design and working code to measure progress.

Slide 20:

The next several slides present a representative format for the SRS. Much of this format is applicable to backlogs in Agile projects as well. In any project, the information mentioned here should be documented somewhere.

The first section is the Introduction. This section forms a large portion of the Project Vision in some Agile methodologies. The project goals are the business reasons this project is being undertaken. How will the eventual product help the company doing the development? The business stakeholders are the areas of this company that are concerned with the success of this project and with the form of the resulting product. Business stakeholders might include:

• Upper management which is providing the resources to undertake this project

• Legal which might need to ensure the product meets applicable laws and regulations.

• Accounting which might need to ensure the product follows accepted accounting procedures including supporting user privacy, and necessary audit trails.

• Sales and Marketing which might need to ensure the product will be a viable competitor when released and that special times such as the Christmas season for consumer products or the end of fiscal year for commercial products are not missed.

• The departments of the intended users, if the product is intended for internal use.

The intended audience is the specific individuals or business roles who need to access and understand the requirements.

The project scope gives a high level, often tentative description of which features and non-functional requirements should be supported by the product. The expected duration and level of staffing for the project are given here.

Document conventions explains the use of any special formats or fonts within the Software Requirements Specification. For example, italics might be used to indicate examples.

The entire introduction is supposed to be short. Five typed pages is ideal, but more than twenty pages is too long.

Slide 21:

The next section is a product overview. This section often is the last section read by non-technical readers.

The Potential Users described the groups of individuals (often by their business roles) expected to use the product.

The next subsection describes how each of these types of expected users will employ the product.

The Operating Environments lists all the environments in which the product is expected to operate. These descriptions might include hardware, browser versions, operating system versions, and any supporting software such as database management systems.

The modes the product should support are described also. A mode might be as a standalone application, as software as a service, as a cloud application under Continuous Deployment, etc.

Assumptions and Dependencies presents any requirements the product has on its user or on other hardware or software. For example, the product might require the user to understand gene splicing and be familiar with its terminology. The product might require that a new computer being developed by the same company be available at least six months before the product.

Slide 22:

The next section lists the current requirements divided into the categories presented earlier. The functional requirements should be divided into those saved for consideration in a future release, those already satisfied in earlier releases, those satisfied in the current release, and those remaining to be satisfied in the current release. Wthin the last category, the requirements should be further divided into those satisfied in an earlier iteration, those satisfied in the current iteration, and those yet to be satisfied in the current iteration. Of course, this last division is done only if an iterative lifecycle is used.

Within each of these classifications, the requirements should be further classified by one of the criteria described when we discussed System Modeling. Those included: by feature, by user data used, and by co-location.

Remember that classification into Satisfied and not yet satisfied is always tentative. Any requirement can move from satisfied to unsatisfied when a problem is discovered. A requirement can move from unsatisfied to satisfied when the developers believe it should be.

Each requirement should have its originator’s name and position associated with it. The date it was first documented and the dates of each subsequent modification should be associated with the requirement also.

Slide 23:

The final section is an important one. The Glossary is a lexicographic ordering of definitions of all the noun phrases and some of the verbs used anywhere in the requirements. These definitions should be clear, unambiguous, and complete. They must be understood in the same way by all the readers of the Requirements document. Examples should be included when an example aids understanding.

Remember that some Agile methodologies place the Glossary as a standalone Data Dictionary.

Slide 24:

The Software Requirements Specification or the backlogs should satisfy sevral properties. These properties are not always easy to establish, but a requirements description that does not satisfy all eight properties often leads to communication problems.

Correct means the requirements express the true needs of the business stakeholders as accurately as possible. Of course, it is very likely that user expectations will change enough over the project to force modifications to the requirements. Noticing and responding to these changes is usually the key to a successful project. Nevertheless, the developers should try to keep the requirements as correct as they can.

Unambiguous means the requirements mean the same thi ng to all concerned parties. The developers need to understand how the business stakeholders intend a requirement.

Complete means the requirements should fully address their overall purpose. If this is the list of requirements for the current release, that list should describe everything the release must provide. If the list is for the current iteration, the list should describe everything currently expected in this iteration.

Consistent means there is no place where a requirement contradicts what another requirement states. For example, if one requirement stated a user id could contain punctuation and another requirement stated the id could not containan ampersand, that would be inconsistent. If and when a developer discovers an inconsistency, the relevant business stakeholders must be consulted to resolve the inconsistency.

Slide 25:

The requirements must be traceable through the design to the code and associated test cases.

The requirements must be prioritized, generally by the concerned busiess stakeholders. This prioritization allows the developers to make decisions as to what to implement first that are consistent with business stakeholder expectations. If the sacrifice or one or more requirements from the current iteration is necessary to meet the scheduled ending date of the iteration, the developers can make reasonable, business stakeholder decisions as to what to delay.

Finally, the requirements should be testable. This means the developers can write test cases that establish whether or not a requirement or group of requirements have been satisfied.

Slide 26:

Finall, we are returning to methods for doing each of the activities of requirements engineering. We finished the first four before discussing the requirements document. There are only two left.

In the Validation activity we make a final check of the requirements individually before we move to either Design or test-driven development, depending on the methodology. Remember that the sixth activity, Management of Requirements occurs throughout development.

In the Validation activity the properties checked overlap somewhat with those mentioned earlier. The first two are new, however.

Atomic means the requirement describes only one thing. For example, the requirement

A student may enroll in undergraduate and graduate courses

Is not atomic because the product can partially satisfy this requirement by supporting enrollment in one type of course, but not the other type. This requirement should be divided in two:

A student may register in undergraduate courses.

A student may register in graduate courses.

Note that the requirement:

A student may register in courses

Could be ambiguous because some might interpret it to mean only certain types of courses while others might interpret it to mean any possible course.

Each requirement must have an identifier or name which is unique among all the requirements. A unique identifier or name allows the requirement to be referenced without any ambiguity in any context.

Slide 27:

The final activity in Requirements Engineering is Requirements Management. Management works during the other activities to ensure developers and business stakeholders work together to determine requirement priorities and to select the requirements to be attempted in the current release and the current iteration.

When the other activities are not active, management does three tasks:

• Track the currently active requirements through design, coding, and testing.

• Control revisions to the currently active requirements

• Maintaining a variety of sub-lists of requirements.

Slide 28:

Requirements Engineering starts by trying to identify as many potential requirements as possible. The relevant business stakeholders are the sources for potential requirements.

Different development methodologies have different goals for this elicitation of requirements. The three possibilities are given on this slide.

The other Requirements Engineering activities other than management, try to refine and reduce the set of potential requirements to those requirements that will be satisfied by the current release or the current iteration.

Non-functional requirements tend to be more abstract than functional requirements. The greater abstractness makes them more difficult to discover and prioritize. The diffuse, difficult to predict impact of some non-functional requirements on the functional requirements makes testing non-functional requirements difficult.

Finally, developers must always remember that requirements are the primary means of communication among developers, business stakeholders, and eventual users. The biggest potential source of miscommunication is poorly stated or incompletely discovered requirements. Miscommunication is the largest reason for project failure.