When starting any software project,
an extremely critical part is to learn what the customer actually
wants and needs and define that clearly for our developers.
As a requirements engineer,
you're playing a really exciting role in fully
learning about the system that was and the system to be.
You are the face to the customer and the liaison between
the customer and the developers and the rest of the software development team.
It's an extremely important role and
the first step toward creating secure successful software.
That is the key focus of this Software Requirements and Specifications Specialization.
Requirements engineers end up touching and
affecting almost all parts of the software development process.
And its important for all involved in that process to understand
how the process works and how it affects you.
Either if you aren't the one doing the writing.
The specialization will help requirements
engineers even those who have worked in the field for many many years.
It will help those because we will be discussing many alternative life cycle approaches,
different environments and new techniques that can be used to expand your current view.
Software engineers, development and product managers,
testers, QA and analysts,
product analysts, technical writers and
security engineers will also all benefit from the specialization.
This is because you all must work with and understand
these technical software requirements specifications in order to perform your jobs well.
And developers and software engineers,
you're often creating these documents or some versions of these documents yourselves tip.
For anyone seeking a graduate degree,
certificate or professional degree in computer science or software engineering,
these courses will additionally give you
a broad understanding of how requirements engineering is
performed and help you to get that first foot forward into your upcoming career.
While the requirements task is quite daunting especially for new requirements engineers,
the courses and the specialization will teach you
the techniques and tips that can help you to succeed.
We will cover many topics used in
the requirements engineering process leading up to full documentation.
Within these topics, domain understanding and elicitation will be
explained with consideration of
deferred software development life cycles that are commonly used.
We'll first gain an understanding of the software development life cycles such as
waterfall spiral and agile models along with their advantages and their disadvantages.
Then, we'll see how we can begin interacting with our customers.
First, we gain domain knowledge,
learning about the area in which we're working.
Then we move into finding out what the customer has now,
what they want and what they actually need.
We do this to artifact and stakeholder driven elicitation.
We then move into evaluation and negotiation techniques.
As we learn what customers need versus what they want,
we can begin writing down system goals and firm requirements.
Within evaluation, we identify language conflicts in vagueness.
For example, if the stakeholders talking about a requirement for a patron of a library.
Well, what's a patron?
Do they have to check out a book in order to be a patron?
Do they just need to enter the library? Who are they?
Language conflicts can also arise by
stakeholders using different terms for the same thing.
One might be talking about a library computer user.
One might say a book borrower,
another might say a book returner.
Do all of these apply to the overall term of patrons?
Are they exactly the same thing or does it need to be subdivided?
In language evaluation, we try to mitigate the risk of vagueness and ambiguity early
on to create clear definitions that can be used in stating key system goals.
Goals can then define what is or must be achieved,
avoided and maintained in the system to be and in the system that is,
clarifying our document more early on.
By removing vagueness and ambiguity,
some negotiation will be necessary.
Additionally, you'll find that some statements may conflict either weakly or strongly.
These conflicts also require negotiation and
may require determination of alternative approaches.
As we come up with alternative approaches to remove conflicts to
fit with overall budget estimates and systems requirements,
risk needs to be assessed and options prioritized.
This is especially true for
non-functional requirements like efficiency, usability and security.
Following evaluation, risk analysis,
negotiation and prioritization, we end up with a set of agreed upon requirements.
Next, we asked how to turn all of these into complete, consistent, concise documents.
We use both natural language and diagrams to show
our customers that we understand their needs and have
documented all of them to their satisfaction
and then we pass on this information to the designers,
the developers, the testers,
the maintainers and others,
so they can all start on their tasks.
The requirements document is
a living document and thus you will enter double of your work through these cycles,
moving steadily more and more to a complete consistent document over time.
You learn more in each iteration,
giving more emphasis to different components over time,
similar to what is done in the iterative model of the software development life cycle.
In the specialization, we will work through all of
these processes with the goal of creating good,
secure, useful products that will make your customers happy.
They will also help developers and others involved to create
the right product and create that product correctly and efficiently.
Overall, these techniques will help lead to overall project success.
Kristen Walcott-JusticeAssistant Professor
