Requirement Challenges

Loading...

En provenance du cours de University of Colorado System

Requirements Gathering for Secure Software Development

50 notes

University of Colorado System

Requirements Gathering for Secure Software Development

50 notes

Cours 1 sur 5 dans Specialization Requirements Engineering: Secure Software Specifications

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.

À 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

Rencontrer les enseignants

Kristen Walcott-Justice
Assistant Professor
Department of Computer Science

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.

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

Télécharger dans l'App Store

Disponible sur Google Play