As requirements are being gathered and prioritized, they also need to be documented. In Diagrammatic Notations and Software Requirements Specification Writing, we discuss and practice the process of turning requirements into something readable to the customers at a high level, and the developers. When a designer or developer reads your document, they should be able to understand the overall idea, the scope, the domain, the resources, the expectations, and why alternative choices are not selected. To create a document in this way, you use a balance between storytelling (with pictures!) and complex diagrams.
Global Organization Templates
Loading...
Из курса от партнера University of Colorado System
SRS Documents: Requirements and Diagrammatic Notations
3 оценки
University of Colorado System
3 оценки
Курс 5 из 5 — Specialization Requirements Engineering: Secure Software Specifications
Из урока
Beginning to Write an SRS Document
Beginning to write a Software Requirements Specification (SRS) is a daunting process. As you start elicitation and move onward through the requirements cycle, you should plan your approach and begin writing as soon as possible. In this module, we discuss local and global rules that should be followed to lead to success.
Познакомьтесь с преподавателями
Kristen Walcott-JusticeAssistant Professor
Department of Computer Science
In addition to the preceding rules constrain the use of
natural language also known as those "local rules".
There are also global rules that constrain the organization of the overall document.
For greater document cohesion,
requirements document items that directly relate to
a common factor should be grouped in the same section.
Common factors can include things like system objectives,
system components, tasks, conceptual objects, or software features.
Thankfully, depending on the type of document that you're
writing and the type of life cycle in which you're working,
there are many templates out there that you can follow.
The IEEE Standard-830 is one of the more commonly used templates.
Many templates are derived from these,
and you can use any to fit your situation.
The first step that you want to take is to write the introduction to the document.
In that introduction, you're talking about the system-to-be,
the domain, the scope, the purpose.
Make the terminology very precise and define all domain-specific concepts.
Elicitation sources also should be listed here,
that will go into your references section.
You can begin writing this section early on in your process as
your full understanding of the system to be isn't really yet needed.
However, you will want to keep going over this section over, and over,
and over again to keep revising it and
make sure that it's actually accurate as your knowledge grows.
The second section of a requirements document is usually a general description.
This general description describes the relationship of the software to
be based on its overall environment.
This has to be specified in terms of interfaces and modes of interaction
with other users' devices and other software.
The general description also gives an overview of the key expected functionalities,
and the expected assumptions,
and about the expected software users.
This includes not only a description of the roles involved but also the experience and
the expertise of the people who are going to be
working with your system and dealing with you.
Next, in the general description,
give an overview of the constraints that will restrict development options.
These may include things like hardware limitations, implementation platforms,
critical concerns, regulations, safety requirements,
and required protocols like security,
and the list goes on and on.
Also here, you will be listing
any environmental factors that might affect
the requirements if any of the environmental factors change.
This section is especially important given security and should be considered early.
Lastly, given your current elicitation,
document what is optional and what might be delayed until future versions.
In agile life cycle,
you might think of this as your ice box for many of your future tests.
All key functionalities though should be listed in section 2.2.
These are the functionalities of the software to be that have to be there.
Now, here we have another way to look at this part of the document
in slightly simpler language – identify the purpose of the SRS,
the software requirements specification,
describe the intended audience.
Then in section 1.2,
identify the software product and enumerate
what that system is going to do and what it will not do.
Also, describe the user classes and the benefits for each.
In section 3, define the vocabulary or you can go reference and appendix.
In section 1.4, you list all reference documents including your sources.
For example, how did you get your domain knowledge?
Did you get domain knowledge from past documents?
If so, what were they?
Were they from clients,
or stakeholders, or where?
List all of that.
Then, in section 1.5,
you want to describe the content of the rest of
the SRS and describe how the SRS is organized.
Think of this section,
section 1.5, as a big summary.
Lastly, with respect to this outline,
section 1.6 describes your risk analysis.
Risk, again, can come from any kind of nonfunctional risk,
from security, to performance,
to usability et cetera.
Include your risk template if you have one.
These could include also,
risk analysis matrices which I discussed in
the course risk analysis, assessment, and prioritization.
And these are based on full system risks.
Now, as we move on to section 3,
section 3 is the core of the requirements document.
The rest is certainly very important but this is going to be your biggest part.
All requirements are detailed here.
The IEEE Standard-830 Standard provides alternative templates of
this particular section and the specifier may
select whatever you feel most appropriate for the domain and the type of system.
Now, right here on this slide,
we have just one example.
Note the structuring in terms of the functional requirements,
and also the different types of nonfunctional requirements.
This example focuses mostly on the nonfunctional requirements
where the functional requirements are only really
listed at the beginning and in section 3.1.
In section 3-2, we focus on interoperability as part of the external interface.
Then, in 3-3, we started
looking into more nonfunctional requirements
like time and space performance requirements.
Then in 3.4, we consider quality requirements which could affect the design constraints.
Then in 3.5, we go into the quality requirements.
Pretty much anything else given in this template goes into section 3.6.
This may include any additional security,
reliability, or maintainability requirements.
The IEEE Standard-830 also has alternative templates based on modes,
user classes, concepts, where those concepts could be objects or classes,
features, stimuli, and organizations.
Now, here we have another example of
the third section with less focus on the nonfunctional requirements.
Pick the template that is best for you.
Note that many working in
an Agile environment prefer to write requirements based on features.
So pause for just a second now.
Just take a look at this slide.
What is different?
External interfaces here details all inputs and outputs that
complement but do not duplicate the information that you wrote in section 2.
You can discuss GUI screens, required formats,
required file formats, APIs,
Lo-fi UI diagrams, small storyboards.
All of that kind of stuff would go here.
You could also talk about things like server connections and so much more.
Section 3.2 will likely be your biggest section explaining detailed specifications,
requirements, scenarios, and use cases.
And with those, you're going to have some diagrams and
tables to help understanding along the way.
We'll get into how we create those in just a minute.
When getting into logical database requirements, which is section 3.4,
include the inputs and outputs needed and the inputs and outputs that are available.
This includes the type of information used,
the data entities, and their relationships to each other.
These help developers, especially to understand what kinds of
information they can be getting from databases and external resources or APIs,
and how they can get it. What is included?
Section 3.5 is design constraints.
This section should include a standards or security compliance.
This information reins in your developers and
tells them what is necessary in terms of their design.
You aren't telling them how to do their job but you're telling them,
this is what is required for this program.
Security protocols especially should be included in the section.
Finally, in section 3.7 in this template,
we are relating to object-oriented models.
Here, you're getting into the nitty-gritty components.
You can organize a section like this based off of architecture specifications,
class diagrams, state and collaboration diagrams, or activity diagrams.
Activity diagrams are especially useful in
representing the needed concurrent or distributed behavior.
And these are all discussed in other lectures in this course.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2019 Все права защищены.
