Requirements - CL2 Flashcards
Non-functional requirements
In addition to the functional requirements, the SRS contains
nonfunctional requirements. These include performance goals and
descriptions of quality attributes. Quality attributes augment the
description of the product’s functionality by describing the product’s
characteristics in various dimensions that are important either to users or
to developers. These characteristics include usability, portability, integrity,
efficiency, and robustness. Other nonfunctional requirements describe
external interfaces between the system and the outside world, and
design and implementation constraints. Constraints impose restrictions
on the choices available to the developer for design and construction of
the product.
In systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements.[1]
Broadly, functional requirements define what a system is supposed to do and non-functional requirements define how a system is supposed to be. Functional requirements are usually in the form of “system shall do “, an individual action or part of the system, perhaps explicitly in the sense of a mathematical function, a black box description input, output, process and control functional model or IPO Model. In contrast, non-functional requirements are in the form of “system shall be “, an overall property of the system as a whole or of a particular aspect and not a specific function. The system’s overall properties commonly mark the difference between whether the development project has succeeded or failed.
Non-functional requirements are often called “quality attributes” of a system. Other terms for non-functional requirements are “qualities”, “quality goals”, “quality of service requirements”, “constraints”, “non-behavioral requirements”,[2] or “technical requirements”.[3] Informally these are sometimes called the “ilities”, from attributes like stability and portability. Qualities—that is non-functional requirements—can be divided into two main categories:
- Execution qualities, such as safety, security and usability, which are observable during operation (at run time).
- Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the system.
Link:
https://en.wikipedia.org/wiki/Non-functional_requirement
Product champion
The Product Champion
The product champion approach provides an effective way to structure the customer-development partnership.
Trap: Watch out for user managers or for software developers who think they already understand the needs of the real system users without asking.
Each product champion serves as the primary interface between members of a single user class and the project’s requirements analyst.
Ideally, the champions will be actual users, not surrogates such as funding sponsors, procuring customers, marketing staff, user managers, or software developers pretending to be users. Product champions
collect requirements from other members of the user classes they represent and reconcile inconsistencies. Requirements development is thus a shared responsibility of the analysts and selected customers,
although the analyst writes the requirements documents.
The best product champions have a clear vision of the new system and are enthusiastic about it because they see how it will benefit them and their peers. The champions should be effective communicators who are
respected by their colleagues. They need a thorough understanding of the application domain and the system’s operating environment. Great product champions are in demand for other assignments on their
principal job, so you’ll have to build a persuasive case for why particular
individuals are critical to project success. My team and I found that good product champions made a huge difference in our projects, so we happily offered them public reward and recognition for their contributions.
The product champion approach works best if each champion is fully empowered to make binding decisions on behalf of the user class he represents. If a champion's decisions are routinely overruled by managers or by the software group, the champion's time and goodwill are being wasted. However, the champions must remember that they are not the sole customers. Problems arise when the individual filling this critical liaison role doesn't adequately communicate with his peers and presents only his own wishes and ideas.
External Product Champions
When developing commercial software, it can be difficult to find people to serve as product champions from outside your company. If you have a close working relationship with some major corporate customers, they
might welcome the opportunity to participate in requirements elicitation. You might give external product champions economic incentives for their participation. Consider offering them discounts on products or paying for the time they spend working with you on requirements. You still face the challenge of how to avoid hearing only the champions’ requirements and neglecting the needs of other customers. If you have a diverse customer base, first identify core requirements that are common to all customers.
Then define additional requirements that are specific to individual customers, market segments, or user classes.
Product Champion Expectations To help the product champion approach succeed, document what you expect your champions to do. These written expectations can help you build a case for specific individuals to fill this critical role. 1. Planning - Refine the scope and limitations of the product - Define interfaces to other systems - Evaluate impact of new system onbusiness operations - Define a transition path from current applications 2. Requirements - Collect requirements from other users - Develop usage scenarios and use cases - Resolve conflicts between proposed requirements - Define implementation priorities - Specify quality and performance requirements - Evaluate user interface prototypes 3. Validation and Verification - Inspect requirements documents - Define user acceptance criteria - Develop test cases from usage scenarios - Provide test data sets - Perform beta testing 4. User Aids - Write portions of user manuals and help text - Prepare training materials for tutorials - Present product demonstrations to peers 5. Change Management - Evaluate and prioritize defect corrections - Evaluate and prioritize enhancement requests - Evaluate the impact of proposed requirements changes on users and business processes - Participate in making change decisions
Multiple Product Champions
One person can rarely describe the needs for all users of an application.
Selling the Product Champion Idea
Expect to encounter resistance when you propose the idea of having product champions on your projects. “The users are too busy.” “Management wants to make the decisions.” “They’ll slow us down.” “We can’t afford it.” “I don’t know what I’m supposed to do as a product champion.” Some users won’t want to provide input on a system that they fear will make them change the way they work or might threaten their job with elimination. Managers are sometimes reluctant to delegate authority
for requirements to ordinary users. Separating business requirements from user requirements alleviates
these discomforts. As an actual user, the product champion makes
decisions at the user requirements level within the constraints that the
project’s business requirements impose. The management sponsor
retains the authority to make decisions that affect the product vision,
project scope, schedule, and cost. Documenting and negotiating the
product champion’s role and responsibilities give candidate champions a
comfort level about what they’re being asked to do.
If you encounter resistance, point out that insufficient user involvement is
well established as a leading cause of software project failure (The
Standish Group 1995). Remind the protesters of problems they’ve
experienced on previous projects that trace back to inadequate user
involvement. Every organization has horror stories of new systems that
didn’t satisfy user needs or failed to meet unstated usability or
performance expectations. You can’t afford to rebuild or discard systems
that don’t measure up because no one understood the requirements.
Product champions mitigate this risk.
Product Champion Traps to Avoid
The product champion model has succeeded in many environments. It
works only when the product champion understands and signs up for his
responsibilities, has the authority to make decisions at the user
requirements level, and has the time to do the job. Watch out for the
following potential problems:
- Some managers override the decisions that a qualified and duly
authorized product champion makes. Perhaps the manager has a
wild new idea at the last minute, wants to change the project
direction at a whim, or thinks he knows what the users need. This
behavior often results in dissatisfied users, late deliveries as the
developers chase the latest management notion, and frustratedproduct champions who feel that management doesn’t trust them.
- A product champion who forgets that he is representing other
customers and presents only his own requirements won’t do a
good job. He might be happy with the outcome, but others likely
won’t be.
- A product champion who lacks a clear mental image of the new
system might defer important decisions to the analyst. If any idea
that the analyst has is okay with the champion, the champion isn’t
much help.
- A senior user might nominate a less experienced user as
champion because he doesn’t have time to do the job himself.
This can lead to backseat driving from the senior user who still
wishes to strongly influence the project’s direction.
- True Stories Beware of users who purport to speak for a user
class to which they do not belong. On Contoso’s Chemical
Tracking System, the product champion for the chemical
stockroom staff also insisted on providing what she thought were
the needs of the chemist user class. It was difficult to convince
her that this wasn’t her job, but the analyst didn’t let her intimidate
him. The project manager lined up a separate product champion
for the chemists, and he did a great job of collecting, evaluating,
and relaying that community’s requirements.
User classes and their characteristics
User Classes
A product’s users differ, among other ways, in the following respects:
The frequency with which they use the product
Their application domain experience and computer systems
expertise
The features they use
The tasks they perform in support of their business processes
Their access privilege or security levels (such as ordinary user,
guest user, or administrator)
You can group users into a number of distinct user classes based on
these differences. An individual can belong to multiple user classes. For
example, an application’s administrator might also interact with it as an
ordinary user at times.
- Stakeholders
- Others
- Customers
- Procurers Managers
- Users
- Favored User Classes
- Disfavored User Classes
- Ignored User Classes
- Other User Classes
Certain user classes are more important to you than others. Favored user
classes receive preferential treatment when you’re making priority
decisions or resolving conflicts between requirements received from
different user classes. Favored user classes include those groups whose
acceptance and use of the system will cause it to meet—or fail to meet—
its business objectives. This doesn’t mean that the stakeholders who are
paying for the system (who might not be users at all) or who have the
most political clout should necessarily be favored. Disfavored user
classes are those groups who aren’t supposed to use the product for
legal, security, or safety reasons (Gause and Lawrence 1999). You might
elect to ignore still other user classes. They get what they get, but you
don’t specifically build the product to suit them. The remaining user
classes are of roughly equal importance in defining the product’s
requirements.
Each user class will have its own set of requirements for the tasks that
members of the class must perform. They might also have different
nonfunctional requirements, such as usability, that will drive user
interface design choices. Inexperienced or occasional users are
concerned with how easy the system is to learn (or relearn) to use. These
users like menus, graphical user interfaces, uncluttered screen displays,
verbose prompts, wizards, and consistency with other applications they
have used. Once users gain sufficient experience with the product, they
become more concerned about ease of use and efficiency. They nowvalue keyboard shortcuts, macros, customization options, toolbars,
scripting facilities, and perhaps even a command-line interface instead of
a graphical user interface.
Trap Don’t overlook indirect or secondary user classes. They might
not use your application directly, instead accessing its data or
services through other applications or through reports. Your
customer once removed is still your customer.
It might sound strange, but user classes need not be human beings. You
can consider other applications or hardware components with which your
system interacts as additional user classes. A fuel injection system would
be a user class for the software embedded in an automobile’s engine
controller. The fuel injection system can’t speak for itself, so the analyst
must get the requirements for the fuel-injection control software from the
engineer who designed the injection system.
Identify and characterize the different user classes for your product early
in the project so that you can elicit requirements from representatives of
each important class. A useful technique for this is called “Expand Then
Contract” (Gottesdiener 2002). Begin by brainstorming as many user
classes as you can think of. Don’t be afraid if there are dozens at this
stage, because you’ll condense and categorize them later. It’s important
not to overlook a user class because that will come back to bite you later.
Next, look for groups with similar needs that you can either combine or
treat as a major user class with several subclasses. Try to pare the list
down to no more than about 15 distinct user classes.
Document the user classes and their characteristics, responsibilities, and
physical locations in the SRS. The project manager of the ChemicalTracking System discussed in earlier chapters identified the user classes
and characteristics shown in Table 6-1. Include all pertinent information
you have about each user class, such as its relative or absolute size and
which classes are favored. This will help the team prioritize change
requests and conduct impact assessments later on. Estimates of the
volume and type of system transactions help the testers develop a usage
profile for the system so that they can plan their verification activities.
Software Quality Attributes
Several dozen product characteristics can be called quality attributes
(Charette 1990), although most projects need to carefully consider only a
handful of them. If developers know which of these characteristics are
most crucial to project success, they can select architecture, design, and
programming approaches to achieve the specified quality goals (Glass
1992; DeGrace and Stahl 1993). Quality attributes have been classified
according to various schemes (Boehm, Brown, and Lipow 1976; Cavano
and McCall 1978; IEEE 1992; DeGrace and Stahl 1993). One way to
classify attributes distinguishes those characteristics that are discernible
at run time from those that aren’t (Bass, Clements, and Kazman 1998).
Another approach is to separate the visible characteristics that are
primarily important to the users from under-the-hood qualities that are
primarily significant to technical staff. The latter indirectly contribute to
customer satisfaction by making the product easier to change, correct,
verify, and migrate to new platforms.
Table 12-1 lists several quality attributes in both categories that every
project should consider. Some attributes are critical to embedded
systems (efficiency and reliability), whereas others might be especially
pertinent to Internet and mainframe applications (availability, integrity, and
maintainability) or to desktop systems (interoperability and usability).
Embedded systems often have additional significant quality attributes,
including safety (which was discussed in Chapter 10), installability, and
serviceability. Scalability is another attribute that’s important to Internet
applications.
Software Quality Attributes Important Primarily to Users - Availability - Efficiency - Flexibility - Integrity - Interoperability - Reliability - Robustness - Usability Important Primarily to Developers - Maintainability - Portability - Reusability - Testability
In an ideal universe, every system would exhibit the maximum possible
value for all its attributes. The system would be available at all times,
would never fail, would supply instantaneous results that are always
correct, and would be intuitively obvious to use. Because nirvana is
unattainable, you have to learn which attributes from Table 12-1 are most
important to your project’s success. Then define the user and developer
goals in terms of these essential attributes so that designers can make
appropriate choices.
Different parts of the product need different combinations of quality
attributes. Efficiency might be critical for certain components, while
usability is paramount for others. Differentiate quality characteristics that
apply to the entire product from those that are specific to certain
components, certain user classes, or particular usage situations.
Document any global quality goals in section 5.4 of the SRS template
presented in Chapter 10, and associate specific goals with individual
features, use cases, or functional requirements.
Assumptions, constraints and their roles
Assumptions
An assumption is a belief of what you assume to be true in the future. You make assumptions based on your knowledge, experience or the information available on hand. These are anticipated events or circumstances that are expected to occur during your project’s life cycle.
Assumptions are supposed to be true but do not necessarily end up being true; Sometimes, they may turn out to be false, which can affect your project significantly. They add risks to the project because they may or may not be true.
Suppose in our shopping example; you assumed that it would take one hour for you to reach the destination. What will happen if, due to traffic, you don’t reach the mall on time?
Your assumption is false, and your plan for shopping is endangered.
This can also happen to your project.
For example, you have assumed that some particular equipment will be made available to you whenever you need it. However, the equipment is not provided when the time comes.
Now, you are in a difficult situation.
Assumptions play an essential role in developing a risk management plan. Therefore, as a project manager, you must collect and identify as many assumptions as you can. It will assist you in developing a sound risk management plan.
The following are a few instances of assumptions:
- You will get all the resources required by you.
- During the rainy season, cheap labor will be available.
- All relevant stakeholders will come to the next meeting.
Constraints
Constraints are limitations imposed on the project, such as the limitation of cost, schedule, or resources, and you have to work within the boundaries restricted by these constraints. All projects have constraints, which are defined and identified at the beginning of the project.
The PMBOK Guide recognizes six project constraints: scope, quality, schedule, budget, resource, and risk. Out of these six, scope, schedule, and budget are collectively known as the triple constraints.
A constraint can be of two types:
Business Constraints
Technical Constraints
Business Constraints
Business constraints depend on the state of your organization; for example, time, budget, resource, etc.
Technical Constraints
Technical constraints limit your design choice. For example, let’s say you’re constructing a pipeline, and according to the design, your pipeline should be able to withstand a certain amount of pressure. This pressure limit is your technical constraint.
So now you know that every project has constraints; therefore, you must identify all your project constraints (such as any milestone, scope, budget, schedule, availability of resources, etc.), and develop your plan accordingly.
Constraints are outside of your control. They are imposed upon you by your client, organization, or by any government regulations.
There is an interesting fact about the constraints: If the constraints become false or are no longer valid, it is more likely that your project will benefit from it.
The following are a few instances of constraints:
You must complete 25% of the work within the first 30 days.
You have to work with the given resources.
You will be given only two site engineers.
Summary
As you can see how important the assumptions and constraints are for your project. An assumption is anything you think to be true but there is no guarantee, and a constraint is a limitation on you and your project. Assumptions and constraints can be anything; they might be related to human resources, budget, time or any kind of functionally.
Assumptions need to be analyzed, and constraints need to be identified.
As a project manager, you must analyze how assumptions and constraints affect your project and what will happen if any assumption fails or any constraint gets resolved or turns out to be false. If you handle your project constraints and assumptions appropriately, it will help you deliver your project on time while meeting stakeholders’ expectations.
Link:
https://pmstudycircle.com/2012/10/assumptions-and-constraints-in-project-management/comment-page-1/
Basic Modeling techniques:
- Data dictionary and glossary
- Data flow diagrams
- ERD
- Process modeling (flowcharts, activity diagrams)
The Software Requirements Specification
The software requirements specification is sometimes called a functional
specification, a product specification, a requirements document, or a
system specification, although organizations do not use these terms in
the same way. The SRS precisely states the functions and capabilities
that a software system must provide and the constraints that it must
respect. The SRS is the basis for all subsequent project planning, design,
and coding, as well as the foundation for system testing and user
documentation. It should describe as completely as necessary the
system’s behaviors under various conditions. It should not contain
design, construction, testing, or project management details other than
known design and implementation constraints.
Several audiences rely on the SRS:
- Customers, the marketing department, and sales staff need to
know what product they can expect to be delivered.
- Project managers base their estimates of schedule, effort, and
resources on the product description.
- The SRS tells the software development team what to build.
- The testing group uses the SRS to develop test plans, cases, and
procedures.
- The SRS tells maintenance and support staff what each part of
the product is supposed to do.
- Documentation writers base user manuals and help screens on
the SRS and the user interface design.
- Training personnel use the SRS and user documentation to
develop educational materials.
- Legal staff ensure that the requirements comply with applicable
laws and regulations.Subcontractors base their work on, and can be legally held to, the
SRS.
As the ultimate repository for the product requirements, the SRS must be
comprehensive. Developers and customers should make no
assumptions. If any desired capability or quality doesn’t appear
somewhere in the requirements agreement, no one should expect it to
appear in the product.
You don’t have to write the SRS for the entire product before beginning
development, but you do need to capture the requirements for each
increment before building that increment. Incremental development is
appropriate when the stakeholders cannot identify all the requirements at
the outset and if it’s imperative to get some functionality into the users’
hands quickly. However, every project should baseline an agreement for
each set of requirements before the team implements them. Baselining is
the process of transitioning an SRS under development into one that has
been reviewed and approved. Working from the same set of
requirements minimizes miscommunication and unnecessary rework.
Organize and write the SRS so that the diverse stakeholders can
understand it. Chapter 1, “The Essential Software Requirement,”
presented several characteristics of high-quality requirements statements
and specifications. Keep the following requirements readability
suggestions in mind:
- Label sections, subsections, and individual requirements
consistently.
- Leave text ragged on the right margin, rather than fully justified.
- Use white space liberally.
- Use visual emphasis (such as bold, underline, italics, and
different fonts) consistently and judiciously.
- Create a table of contents and perhaps an index to help readers
find the information they need.Number all figures and tables, give them captions, and refer to
them by number.
- Use your word processor’s cross-reference facility rather than
hard-coded page or section numbers to refer to other locations
within a document.
- Use hyperlinks to let the reader jump to related sections in the
SRS or in other documents.
- Use an appropriate template to organize all the necessary
information.
The Data Dictionary
Data dictionary—a shared repository that
defines the meaning, data type, length, format, necessary precision, and
allowed range or list of values for all data elements or attributes used in
the application.
The information in the data dictionary binds together the various
requirements representations. Integration problems are reduced if all
developers respect the data dictionary definitions. Begin collecting data
definitions as you encounter them during requirements elicitation. The
data dictionary complements the project glossary, which defines
individual terms. You might want to merge the glossary entries into the
data dictionary, although I prefer to keep them separate. The data
dictionary can be managed as an appendix to the SRS or as a separate
document or file.
Compared with sprinkling data definitions throughout the functional
requirements, a separate data dictionary makes it easy to find the
information you need, and it avoids redundancy and inconsistencies.
Some commercial analysis and design tools include a data dictionary
component. If you set up the data dictionary manually, consider using a
hypertext approach. Clicking on a data item that is part of a data structure
definition would take you to the definition of that individual data item,
thereby making it easy to traverse the hierarchical tree of definitions.
Items in the data dictionary are represented using a simple notation
(DeMarco 1979; Robertson and Robertson 1994). The item being defined
is shown on the left side of an equal sign, with its definition on the right.
This notation defines primitive data elements, the composition of multiple
data elements into structures, optional data items, iteration (repeats) of a
data item, and a list of values for a data item. The following examples are
from the Chemical Tracking System (of course!).Primitive data elements A primitive data element is one for which no
further decomposition is possible or necessary. The definition identifies
the primitive’s data type, size, range of allowed values, and other
pertinent attributes. Primitives typically are defined with a comment,
which is any text delimited by asterisks:
Request ID = * a 6-digit system-generated sequential integer,
beginning with 1, that uniquely identifies each
request *
Composition A data structure or record contains multiple data items. If
an element in the data structure is optional, enclose it in parentheses:
Requested Chemical = Chemical ID
+ Number of Containers
+ Grade
+ Amount
+ Amount Units
+ (Vendor)
This structure identifies all the information associated with a request for a
specific chemical. Vendor is optional because the person placing the
request might not care which vendor supplies the chemical. Each data
item that appears in a structure must itself be defined in the data
dictionary. Structures can incorporate other structures.
Iteration If multiple instances of an item can appear in a data structure,
enclose that item in curly braces. Show the allowed number of possible
repeats in the form minimum:maximum in front of the opening brace:
Request = Request ID
+ Request Date
+ Charge Number
+ 1:10{Requested Chemical}
This example shows that a chemical request must contain at least one
chemical but may not contain more than 10 chemicals. Each request has
the additional attributes of an identifier, the date the request was created,and a charge number to be used for payment.
Selection A data element that can take on a limited number of discrete
values is called an enumerated primitive. Show the possible values in a
list contained within square brackets, with vertical bars separating the list
items:
Quantity Units = [“grams” | “kilograms” | “milligrams” | “each”]
* 9-character text string indicating the units associated
with the quantity of chemical requested *
This entry shows that there are just four allowed values for the text string
Quantity Units. The comment inside the asterisks provides the textual
definition of the data element.
The time you invest in creating a data dictionary will be more than repaid
by the time you save avoiding mistakes that result when project
participants have different understandings of key data. If you keep the
data dictionary current, it will remain a valuable tool throughout the
system’s maintenance life and when developing related systems.
Data Flow Diagram
The data flow diagram is the basic tool of structured analysis (DeMarco
1979; Robertson and Robertson 1994). A DFD identifies the
transformational processes of a system, the collections (stores) of data or
material that the system manipulates, and the flows of data or material
between processes, stores, and the outside world. Data flow modeling
takes a functional decomposition approach to systems analysis, breaking
complex problems into progressive levels of detail. This works well for
transaction-processing systems and other function-intensive applications.
Through the addition of control flow elements, the DFD technique has
been extended to permit modeling of real-time systems (Hatley,
Hruschka, and Pirbhai 2000).
The DFD provides a way to represent the steps involved in a business
process or the operations of a proposed software system. I’ve often used
this tool when interviewing customers, scribbling a DFD on a whiteboard
while we discuss how the user’s business operates. Data flow diagrams
can represent systems over a wide range of abstraction. High-level DFDs
provide a holistic, bird’s-eye view of the data and processing components
in a multistep activity, which complements the precise, detailed view
embodied in the SRS. A DFD illustrates how the functional requirements
in the SRS combine to let the user perform specific tasks, such as
requesting a chemical.
Trap Don’t assume that customers already know how to read
analysis models, but don’t conclude that they’re unable to
understand them, either. Explain the purpose and notations of
each model to your product champions and ask them to review
the diagrams.
The context diagram in Figure 5-3 is the highest level of abstraction of
the DFD. The context diagram represents the entire system as a single
black-box process, depicted as a circle (a bubble). It also shows the
terminators, or external entities, that connect to the system and the data
or material flows between the system and the terminators. Flows on the
context diagram often represent complex data structures, which are
defined in the data dictionary.You can elaborate the context diagram into the level 0 DFD, which
partitions the system into its major processes. Figure 11-1 shows the
level 0 DFD for the Chemical Tracking System (somewhat simplified).
The single process bubble that represented the entire Chemical Tracking
System on the context diagram has been subdivided into seven major
processes (the bubbles). As with the context diagram, the terminators are
shown in rectangles. All data flows (arrows) from the context diagram
also appear on the level 0 DFD. In addition, the level 0 diagram contains
several data stores, depicted as a pair of parallel horizontal lines, which
are internal to the system and therefore do not appear on the context
diagram. A flow from a bubble to a store indicates that data is being
placed into the store, a flow out of the store shows a read operation, and
a bidirectional arrow between a store and a bubble indicates an update
operation.
Each process that appears as a separate bubble on the level 0 diagramcan be further expanded into a separate DFD to reveal more detail about
its functioning. The analyst continues this progressive refinement until the
lowest-level diagrams contain only primitive process operations that can
be clearly represented in narrative text, pseudocode, a flowchart, or an
activity diagram. The functional requirements in the SRS will define
precisely what happens within each primitive process. Every level of the
DFD must be balanced and consistent with the level above it so that all
the input and output flows on the child diagram match up with flows on its
parent. Complex data flows on the high-level diagrams can be split into
their constituent elements, as defined in the data dictionary, on the lower-
level DFDs.
Figure 11-1 looks complex at first glance. However, if you examine the
immediate environment of any one process, you will see the data items
that it consumes and produces and their sources and destinations. To
see exactly how a process uses the data items, you’ll need to either draw
a more detailed child DFD or refer to the functional requirements for that
part of the system.
Following are several conventions for drawing data flow diagrams. Not
everyone adheres to the same conventions (for example, some analysts
show terminators only on the context diagram), but I find them helpful.
Using the models to enhance communication among the project
participants is more important than dogmatic conformance to these
principles.
- Place data stores only on the level 0 DFD and lower levels, not
on the context diagram.
- Processes communicate through data stores, not by direct flows
from one process to another. Similarly, data cannot flow directly
from one store to another; it must pass through a process bubble.
- Don’t attempt to imply the processing sequence using the DFD.
- Name each process as a concise action: verb plus object (such
as Generate Inventory Reports). Use names that are meaningful
to the customers and pertinent to the business or problem
domain.
- Number the processes uniquely and hierarchically. On the level 0
diagram, number each process with an integer. If you create a
child DFD for process 3, number the processes in that child
diagram 3.1, 3.2, and so on.
- Don’t show more than eight to ten processes on a single diagram
or it becomes difficult to draw, change, and understand. If you
have more processes, introduce another layer of abstraction by
grouping related processes into a higher-level process.
- Bubbles with flows that are only coming in or only going out are
suspect. The processing that a DFD bubble represents normally
requires both input and output flows.
When customer representatives review a DFD, they should make sure
that all the known processes are represented and that processes have no
missing or unnecessary inputs or outputs. DFD reviews often reveal
previously unrecognized user classes, business processes, and
connections to other systems.
Entity-Relationship Diagram
Just as a data flow diagram illustrates the processes that take place in a
system, a data model depicts the system’s data relationships. A
commonly used data model is the entity-relationship diagram, or ERD
(Wieringa 1996). If your ERD represents logical groups of information
from the problem domain and their interconnections, you’re using the
ERD as a requirements analysis tool. An analysis ERD helps you
understand and communicate the data components of the business or
system, without implying that the product will necessarily include a
database. In contrast, when you create an ERD during system design,
you’re defining the logical or physical structure of the system’s database.
Entities are physical items (including people) or aggregations of data
items that are important to the business you’re analyzing or to the system
you intend to build (Robertson and Robertson 1994). Entities are named
as singular nouns and are shown in rectangles in an ERD. Figure 11-2
illustrates a portion of the entity-relationship diagram for the Chemical
Tracking System, using one of several common ERD modeling notations.
Notice that the entities named Chemical Request, Vendor Catalog, and
Chemical Stockroom Inventory appeared as data stores in the data flow
diagram in Figure 11-1. Other entities represent actors who interact with
the system (Requester), physical items that are part of the business
operations (Chemical Container), and blocks of data that weren’t shown
in the level 0 DFD but would appear on a lower-level DFD (Container
History, Chemical).
Each entity is described by several attributes; individual instances of an
entity will have different attribute values. For example, the attributes for
each chemical include a unique chemical identifier, its formal chemical
name, and a graphical representation of its chemical structure. The data
dictionary contains the detailed definitions of those attributes, which
guarantees that entities in the ERD and their corresponding data stores
from the DFD are defined identically.
The diamonds in the ERD represent relationships, which identify the
logical and numeric linkages between pairs of entities. Relationships are
named in a way that describes the nature of the connections. For
example, the relationship between the Requester and the Chemical
Request is a placing relationship. You can read the relationship as either
“a Requester places a Chemical Request” or as “a Chemical Request is
placed by a Requester.” Some conventions would have you label the
relationship diamond “is placed by,” which makes sense only if you read
the diagram from left to right. When you ask customers to review an
ERD, ask them to check whether the relationships shown are all correct
and appropriate. Also ask them to identify any possible relationships with
entities that the model doesn’t show.
The cardinality, or multiplicity, of each relationship is shown with a
number or letter on the lines that connect entities and relationships.
Different ERD notations use different conventions to representcardinality; the example in Figure 11-2 illustrates one common approach.
Because each Requester can place multiple requests, there’s a one-to-
many relationship between Requester and Chemical Request. This
cardinality is shown with a 1 on the line connecting Requester and the
placing relationship and an M (for many) on the line connecting Chemical
Request and the placing relationship. Other possible cardinalities are as
follows:
One-to-one (every Chemical Container is tracked by a single
Container History)
Many-to-many (every Vendor Catalog contains many Chemicals,
and some Chemicals appear in multiple Vendor Catalogs)
If you know that a more precise cardinality exists than simply many, you
can show the specific number or range of numbers instead of the generic
M.
Activity Diagrams
Flowcharts and their new incarnation, the UML activity diagram, have the advantage of reasonable
familiarity: even people with no computer-related training or background know what a flowchart is. For
example, a local newspaper recently published a flowchart that described an algorithm by which the
brain processes the decisions involved in purchasing a Saab convertible. For reasons that are pretty
clear, all paths through that particular flowchart ended up at the same activity: “Buy the Saab.” There
must have been a logic error in there somewhere, although we couldn’t find it. But we sure are enjoying
the car!
The problem with activity diagrams, as the technical computer community has learned over the past 30
years, is that they are a nuisance to keep up-to-date. Of course, it can be a nuisance to keep any visual
representation of a requirement up-to-date without automated tools; nobody wants to redraw a state
transition diagram or a decision tree, either.
Requirements artifacts:Product Vision and Scope document etc
The business requirements represent the top level of abstraction in the
requirements chain: they define the vision and scope for the software
system. The user requirements and software functional requirements
must align with the context and objectives that the business requirements
establish. Requirements that don’t help the project achieve its business
objectives shouldn’t be included.
A project that lacks a clearly defined and well-communicated direction
invites disaster. Project participants can unwittingly work at cross-
purposes if they have different objectives and priorities. The stakeholders
will never agree on the requirements if they lack a common
understanding of the business objectives for the product. A clear vision
and scope is especially critical for multisite development projects, where
geographical separation inhibits the day-to-day interactions that facilitate
teamwork.
One sign that the business requirements are insufficiently defined is that
certain features are initially included, then deleted, and then added back
in later. Vision and scope issues must be resolved before the detailed
functional requirements can be fully specified. A statement of the
project’s scope and limitations helps greatly with discussions of proposed
features and target releases. The vision and scope also provide a
reference for making decisions about proposed requirement changes and
enhancements. Some companies print the vision and scope highlights on
a poster board that’s brought to every project meeting so that they can
quickly judge whether a proposed change is in or out of scope.
Defining the Vision Through Business
Requirements
The product vision aligns all stakeholders in a common direction. The
vision describes what the product is about and what it eventually could
become. The project scope identifies what portion of the ultimate long-
term product vision the current project will address. The statement of
scope draws the boundary between what’s in and what’s out. That is, the
scope also defines the project’s limitations. The details of a project’s
scope are represented by the requirements baseline that the team
defines for that project.
The vision applies to the product as a whole. It will change relatively
slowly as a product’s strategic positioning or an information system’s
business objectives evolve over time. The scope pertains to a specific
project or iteration that will implement the next increment of the product’s
functionality, as shown in Figure 5-1. Scope is more dynamic than vision
because the project manager adjusts the contents of each release within
its schedule, budget, resource, and quality constraints. The planner’s
goal is to manage the scope of a specific development or enhancement
project as a defined subset of the grand strategic vision. The scope
statement for each project, or for each iteration or enhancement in an
evolving product, can appear in that project’s SRS, rather than in a
separate vision and scope document. Major new projects should have
both a complete vision and scope document and an SRS. See Chapter
10, “Documenting the Requirements,” for an SRS template.
Conflicting Business Requirements
Business requirements collected from multiple sources might conflict.
Consider a kiosk containing embedded software, which will be used by a
retail store’s customers. The kiosk developer’s business objectives
include the following:
- Generating revenue by leasing or selling the kiosk to the retailer
- Selling consumables through the kiosk to the customer
- Attracting customers to the brand
- Making a wide variety of products available
The retailer’s business interests could include the following:
- Maximizing revenue from the available floor space
- Attracting more customers to the store
- Increasing sales volume and profit margins if the kiosk replaces
manual operations
The developer might want to establish a high-tech and exciting new
direction for customers. The retailer wants a simple turnkey system, and
the customer favors convenience and features. The tension among these
three parties with their different goals, constraints, and cost factors can
lead to inconsistent business requirements. The project sponsor must
resolve these conflicts before the analyst can detail the kiosk’s system
and software requirements. The focus should be on the fundamental
objectives for the product that will deliver the maximum business value
(“increase sales to new and existing customers”). It’s easy to be
distracted by superficial product characteristics (“innovative user
interface that attracts customers”) that don’t really state the business
objective.
It’s also up to the project sponsor (or sponsors) to resolve conflicts
among various business stakeholders, rather than expecting the software
team to somehow figure these out. As more stakeholders are identified
and more constituencies with competing interests climb aboard, the risk
of scope creep increases. Uncontrolled scope creep in which
stakeholders overstuff the new system in an attempt to satisfy every
conceivable interest can cause the project to topple under its own weight,
never delivering anything of value. Resolving such issues is often a
political and power struggle, which lies outside the scope of this book.
Business Requirements and Use Cases
The business requirements determine both the set of business tasks (use
cases) that the application enables (the application breadth) and the
depth or level to which each use case is implemented. If the business
requirements help you determine that a particular use case is outside theproject’s scope, you’re making a breadth decision. The depth of support
can range from a trivial implementation to full automation with many
usability aids. The business requirements will imply which use cases
demand robust, comprehensive functional implementation and which
require merely superficial implementation, at least initially.
The business requirements influence the implementation priorities for use
cases and their associated functional requirements. For example, a
business objective to generate maximum revenue from a kiosk implies
the early implementation of features that sell more products or services to
the customer. Exotic, glitzy features that appeal to only a few technology-
hungry customers and don’t contribute to the primary business objective
shouldn’t have high priority.
Business requirements also materially influence the way requirements
are implemented. For example, one motivation for building the Chemical
Tracking System was to purchase fewer new bottles of a chemical by
increasing the use of chemicals that are already in the stockroom or in
another laboratory. Interviews and observation should reveal why
chemical reuse is not happening now. This information in turn leads to
functional requirements and designs that make it easy to track the
chemicals in every lab and to help a requester find chemicals in other
labs near the requester’s location.
Vision and Scope Document
The vision and scope document collects the business requirements into a
single document that sets the stage for the subsequent development
work. Some organizations create a project charter or a business case
document that serves a similar purpose. Organizations that build
commercial software often create a market requirements document
(MRD). An MRD might go into more detail than a vision and scope
document about the target market segments and the issues that pertain
to commercial success.
The owner of the vision and scope document is the project’s executive
sponsor, funding authority, or someone in a similar role. A requirements
analyst can work with the owner to write the vision and scope document.Input on the business requirements should come from individuals who
have a clear sense of why they are undertaking the project. These
individuals might include the customer or development organization’s
senior management, a project visionary, a product manager, a subject
matter expert, or members of the marketing department.
Figure 5-2 suggests a template for a vision and scope document.
Document templates standardize the structure of the documents created
by your organization’s project teams. As with any template, adapt this
one to meet the specific needs of your own projects.
Parts of the vision and scope document might seem repetitive, but they
should interlock in a sensible way. Consider the following example:
Business Opportunity Exploit the poor security record of a competing
product.
Business Objective Capture a market share of 80 percent by being
recognized as the most secure product in the market through trade
journal reviews and consumer surveys.
Customer Need A more secure product.
Feature A new, robust security engine.
System requirements
The term system requirements describes the top-level requirements for a
product that contains multiple subsystems—that is, a system (IEEE
1998c). A system can be all software or it can include both software and
hardware subsystems. People are a part of a system, too, so certain
system functions might be allocated to human beings.
To be used efficiently, all computer software needs certain hardware components or other software resources to be present on a computer.[1] These prerequisites are known as (computer) system requirements and are often used as a guideline as opposed to an absolute rule. Most software defines two sets of system requirements: minimum and recommended. With increasing demand for higher processing power and resources in newer versions of software, system requirements tend to increase over time. Industry analysts suggest that this trend plays a bigger part in driving upgrades to existing computer systems than technological advancements. A second meaning of the term of System requirements, is a generalisation of this first definition, giving the requirements to be met in the design of a system or sub-system.
Link:
https://en.wikipedia.org/wiki/System_requirements
