Lecture:Course Introduction Video

Loading...

From the course by UNSW Australia (The University of New South Wales)

Requirements Writing

25 оценки

UNSW Australia (The University of New South Wales)

Requirements Writing

25 оценки

Welcome to "Requirements Writing". As the title indicates, over the next four weeks, we will be looking at the important task of writing of text-based requirement statements. The course takes you step by step through the rules for writing requirements statements in accordance with the "Guide for Writing Requirements" published by the International Council on Systems Engineering (INCOSE). This course welcomes anyone who wants to find out how to write requirements. It is relevant to anyone in project management, engineering, QA, logistic support, operations, management, maintenance and other work areas. No specific background is required, and we welcome learners with all levels of interest and experience.

From the lesson

Welcome & Introduction to the Course

Welcome to the Requirements Writing MOOC. The course is run over five weeks. During the first four weeks you will complete four modules (one each week) that progressively move through the rules for writing requirements. Each week, you will have the opportunity to undertake a module quiz as many times as you wish to ensure that you have a grasp on the module material. The quizzes are drawn from a large set of questions, so each time you do the quiz, you will see new questions to test your knowledge. In Week 5, there will not be any presentations but you will have time to review the four modules and practice the module quizzes again so that you are prepared for the course exam.

Lecture:Course Introduction Video5:15

Meet the Instructors

Dr Mike Ryan
Senior Lecturer
School of Engineering and IT

Welcome to the Requirement Writing MOOC.

As the title indicates, over the next five weeks we'll be looking at the important

task of writing text-based requirement statements.

It might not always be obvious why requirements are necessary.

Particularly, since we don't use formal methodologies

in much of our decision making in our personal and business lives.

However, for projects, or as we currently run them at least,

an agreed set of requirements is essential from a number of different perspectives.

First and foremost we need to take the view of business management,

the people who are paying for and are legally responsible for the project.

For them, the set of requirements provides a mechanism

whereby the organization's resources can be allocated knowingly to the project.

Unless the requirement set is well defined, the project has no firm base and

will have an inadequate resources set allocated to it.

From the project manager's perspective, the set of requirements is

an essential part of the definition of the scope of the project.

And it's from this scope that pseudo-estimates have to be developed for

schedule and for budget.

It's not surprising then that scope management is one of the major functions

of a project manager.

A well-defined scope, that is a well-defined set of requirements,

is necessary to be able to justify any expenditure of funds or

effort within the project.

To be able to adequately report on progress of work within the project.

And eventually to be able to determine when the project's complete.

Inadequate requirements is at the top of any list of courses of project failure.

Clearly then, if the project manager doesn't begin with a well-defined

set of requirements that's understood by all parties, the project is going to fail.

And then from the system engineer's perspective,

the formal set of system requirements represents the transition from

the business world into the system's engineering and the engineering worlds.

Once the set's been established,

it's not possible to rectify a full set of requirements with good design,

good engineering or even good production processes.

Consequently, a project can rarely recover from poor definition,

regardless of how much good work is preformed subsequently.

Which again is why poor requirements are at the top of any list

of the causes of project failure.

Now, in addition to all of those issues,

requirement statements at any level of design are the basis of a contract,

a contract between whoever is asking for something and whoever is providing it.

We give those parties various names.

We call them acquirer, supplier, customer, contractor, tasking activity,

performing activity.

And to perform the basis of a contract,

the requirements must be contractually binding.

To be the basis of a fair contract the requirements must therefore at the least

be feasible and able to be verified.

But most of all, they must be clear, they must be unambiguous, and that is,

both parties must have the same understanding of the requirement.

Now, when it comes to writing formal contractually binding statements,

natural language doesn't serve us very well because it can be very hard work,

particularly using common English words to be clear, and to be precise, and

to avoid the ambiguity.

However, if we are careful to avoid that ambiguity, textual requirements are very

powerful because there's no limitation on the concepts that can be expressed.

Now, that's a rather long-winded way of simply saying that we have to be

careful when we write requirement statements.

We need to be able to avoid the ambiguity.

To do that we need some rules.

We need those rules to guide us so that we can talk about unambiguous requirements.

And it's those rules and their application that are the focus of this course.

The courses run over five weeks.

During the first four weeks you'll complete four modules, one for each week.

The modules progressively move through the rules for writing requirements.

Each week you'll have the opportunity to undertake a module quiz, as many times as

you wish, to ensure that you have a grasp on the material covered in that module.

The quizzes are drawn from a large set of questions, so

each time you do the quiz, you'll see new questions to test your knowledge.

In week five there'll not be any presentations, but

you'll have time to review the four modules and

practice the module quizzes again so that you're prepared for the course test.

The test questions are drawn from the same large pool of questions as the quizzes.

So you should not be surprised by those questions since you will have seen

something very familiar if you've been preparing by completing the quizzes at

a sufficient number of times.

Please also note that in addition to the video presentations, quizzes and

tests, we've provided you with a number of useful resources.

You have a bibliography containing the major books covering requirements

engineering and requirements writing.

In particular, we provide a link for a text which has been purposely designed for

this MOOC.

It's not mandatory, you can complete the course with out it, but

I believe that you'll find it useful both during the course and subsequently.

So with all let by way of introduction, when you're ready, see you in module one.

Ознакомьтесь с нашим каталогом

Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.

Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.

© Coursera Inc., 2018 Все права защищены.

Загрузить из App Store

Загрузить в Google Play