Explore
For Enterprise
Join for Free
Log In

Arts et humanités
Business
Informatique
Science des données
Technologies de l'information
santé
Mathématiques et logique
Développement personnel
Sciences physiques et ingénierie
Sciences sociales
Apprentissage des langues
Diplômes
Certificats

Explorez l'intégralité de Coursera

Parcourir
Rechercher
For Enterprise
Connexion
Inscrivez-vous gratuitement

Requirement Challenges

Loading...

Requirements Gathering for Secure Software Development

University of Colorado System

4.5 (139 notes) | 2.5K étudiants inscrits

Cours 1 de 5 dans Requirements Engineering: Secure Software Specifications Spécialisation

In Software Requirements Elicitation for Secure Software Development, we're going to discuss the overall software requirements process as it applies in waterfall, spiral, and agile models. You'll learn about each of these processes and your goals as a software requirements analyst. This is not an easy task! Who do you talk to, when, and what kind of knowledge are you trying to obtain, in any software life cycle? How do you handle obstacles as you go? These are the questions we will focus on answering in this specialization.

Visualiser le programme de cours

Compétences que vous apprendrez

Requirements Elicitation, Requirements Analysis, Software Requirements, Requirements Engineering

Avis

4.5 (139 notes)

5 stars
100 ratings
4 stars
18 ratings
3 stars
11 ratings
2 stars
9 ratings
1 star
1 ratings

RK

Feb 21, 2018

The instructor is too good. And her wit is wonderful.

NM

Mar 12, 2019

The best and advanced way of learning with COURSERA

À partir de la leçon

Goals and Models for Elicitation

To increase flexibility to change in software development, the agile lifecycle was produced. The agile process much changes how we deal with requirements. We discuss these challenges and your role as a requirements analyst. We also begin to analyze the types of statements that you want to form as you elicit data to move towards clarity.

Who, when, why, and how?4:46

Requirement Engineering Statement Types4:24

Requirement Challenges3:56

Enseigné par

Kristen Walcott-Justice
Assistant Professor

Transcription

Making these assumptions, learning domain properties,

and writing clear definitions lead to your ability to elaborate on correct requirements.

This is very easy to mess up and requires our constant thought,

attention, and probably a lot of revision.

You know, I had this issue in one of my courses,

where I told my students that they were required to

participate in at least one class a week.

Also, if they couldn't be present in class,

I needed to be notified,

before the class, so that they would receive

participation credit for the day and not be penalized.

Given that statement, I had a student walk in,

probably 20 minutes late, say,

"Hi," wave and walk out.

Obviously, the definitions in my syllabus were not clear enough.

Requirements are hard.

A common misconception is that the target of

investigation in our software requirements documents,

is just the software itself.

This is not the case though,

you must explore the system of which the software is a component.

Requirements engineering also doesn't amount to

just some translation of pre-existing solutions.

For example, for those of you who have used a common course management tool.

The one that we, that I've been using students say,

"Oh my, this is so annoying," for various reasons.

And they say, "Oh, we need a course project,

we're going to remake this course management software."

First, yes, that was the look on my face and

response because it's utterly unreasonable given the scope,

unless it was a huge 100 person group and they never really wanted to graduate.

But it turned out in questioning the students more

that they didn't want to make changes to,

that they wanted to make changes to the product,

but they didn't understand even a quarter of the components underlying it.

All most of them really wanted to do was to be able to submit their homework,

get a grade, see the grade.

And because of that, they had minor complaints about how the system did that.

Another misconception,

is that requirements is just about figuring out what the users want.

But, it's also actually involving system design.

We can't just view software like we did in the waterfall model.

Often, we need to make decisions that may influence the system design.

Thus, even if you never want to code a single line ever in your life,

it's good to understand coding and good to understand

design because some of your requirements are linked so closely to this,

that you can only really understand them once the design has taken place.

Security is a good example of this,

especially when certain protocols, business rules must be used.

Unlike domain properties, requirements may need to be negotiated, changed or weakened.

When we discuss precise requirements,

we mean that every statement must have a unique,

accurate interpretation without necessarily being machine processable.

You can write requirements formally,

but precise is generally sufficient.

A set of notations may be a necessary condition for requirements engineering methods,

but not a sufficient one.

A requirements engineering method should provide

systematic guidance for building complex requirements documents.

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

© 2019 Coursera Inc. Tous droits réservés.

Télécharger dans l'App Store

Disponible sur Google Play

Coursera
À propos
Direction
Carrières
Catalogue
Certificats
Certificats MasterTrack™
Diplômes
For Enterprise
For Government

Communauté
Learners
Partners
Developers
Beta Testers
Translators

Se connecter
Blog
Facebook
LinkedIn
Twitter
Instagram
YouTube
Blog Tech

Plus
Conditions
Confidentialité
Aide
Accessibilité
Presse
Contact
Répertoire
Filiales