Course syllabus

Course on "Software Requirements Management"
(or soon to be Business Analysis for IT Systems)

1. Lecturers

- Dr. Oktay Turetken (responsible lecturer)
- Dr. Baris Ozkan
- Mr. Rick Gilsing
- Dr. Jan van Moll (Guest lecturer: Head of Quality Management Systems, Philips Health Tech, MRI)

2. Course Content

The engineering history has taught us well that it is essential to have a clear understanding of the problem and the requirements of the solution system in order to successfully design and implement the right solution. This course focuses on the methods and practices that are used to identify the needs and to define IT system solutions that will maximize the value delivered by an organization to its stakeholders. It provides an understanding of the organizational and managerial issues related to the elicitation, analysis, verification and management of IT system requirements.  It covers methods and practices that are applied not only for the implementation of enterprise systems -that support business processes in various domains, but also for the development of innovative commercial software systems. 

In spite of diverse development methods and techniques, complex IT systems are delivered late, over-budget and do not meet the actual needs of the system end-users and the organization that is paying for the system. These failures rarely have technical causes but can often be traced back to the requirements of the system and the process of developing and managing them.

Requirements are specifications of the services that an IT system should provide, the constraints on the system, and the background information that is necessary to develop the system. In the business analysis (or requirements engineering) domain, there are various approaches and methods for the elicitation, analysis, and specification of IT system requirements. Some of them focus on particular phases of the IT system development process, while others cover a specific aspect of system development, e.g. user participation, formal development using mathematical models, etc.

This course will not address a particular overarching method or technique for business analysis. It will cover selected important aspects of the business analysis and requirements engineering process, and techniques applicable to a specific part of this process. The reason for this is that we believe that there is no single overarching method that is effective for or applicable to all types of systems.

We will start with an introduction to business analysis and requirements engineering and briefly discuss IT system development paradigms with respect to business analysis practices. Next, we will continue discussing several (best) practices in the process of requirements development and management. Guest lecturer(s) from industry companies will join us to discuss about a particular course topic and share their experience.

3. Learning Objectives

Business analysis for information technology (IT) systems involves defining needs and designing/describing IT solutions for business problems. These solutions can range from novel commercial software products to large-scale business/enterprise information systems.

Upon completing the course successfully, students will be able to:

1)  explain why business analysis is so important in IT systems development,

2)  explain what the state-of-the-art business analysis concepts and terms are,

3)  explain the major IT systems development paradigms and the role of business analysis practices in each,

4)  explain the process involved in eliciting, analyzing, specifying, verifying, validating, and managing the requirements in IT system development projects,

5)  define high-quality IT system requirements (of different types and at different granularity levels),

6)  develop valid and well-structured documents that specify requirements serving for the needs of different stakeholders.

4. Course Material

The (strongly) recommended textbook for the course:
   K. Wiegers, J. Beatty: Software Requirements, 3rd Ed., Microsoft Press, 2013.

Lecture handouts (and possibly other related material, such as papers) will be made available on CANVAS.

5. Structure and Schedule

This course consists of a plenary component, concluded with a written exam, and a group assignment. In the assignment, the students will be asked to define, specify and review the requirements of a software application (more information in Section 7).

Students are expected to form teams before the deadline (see the schedule below) using CANVAS, to carry out the assignment. The rules regarding the number of team members and the composition will be discussed during the first lecture.

The course schedule, including the lectures and corresponding book chapters, and date/location details are given below:

Course Schedule

Week	Lecture	Topic	Book Chapter*	Lect	Day	Location
Wk0		No lecture in 25 April!!			No lecture in 25 April!!
Wk1	Lecture 1	Introduction	Chp.1 & 3	OT	02.May.2018  Wednesday 15:45 - 17:30 (7+8)	TRAVERSE DORGELOZAAL
	Lecture 2	Elicitation & Analysis	Chp.5, 6, 7, 8	OT	04.May.2018  Friday 10:45 - 12:30 (3+4)	PAVILJOEN L10
	Deadline to form your team for the Assignment				04.May.2018   Friday 19:30
Wk2	Lecture 3	(Service-Dominant) Business Model Design	<additional reading indicated in the handout>	OT	09.May.2018  Wednesday 15:45 - 17:30 (7+8)	TRAVERSE DORGELOZAAL
		TU/e closed - 11 May			TU/e closed - 11 May 2018
Wk3	Lecture 4	IT System Development Paradigms Revisited	Chp.20 (partly)	OT	16.May.2018 Wednesday 15:45 - 17:30 (7+8)	TRAVERSE DORGELOZAAL
	Deadline: AssgA- Vision and Scope Document				17.May.2018 Thursday 17:30
		No lecture in 18 May			No lecture in 18.May.2018 Friday
Wk4	Lecture 5	Quality Requirements	Chp.14	OT	23.May.2018 Wednesday 15:45 - 17:30 (7+8)	TRAVERSE DORGELOZAAL
	Deadline: AssgB- Vision and Scope Review Document				24.May.2018  Thursday 17:30
	Lecture 6	Specification	Chp.10 & 11	OT	25.May.2018 Friday 10:45 - 12:30 (3+4)	PAVILJOEN L10
Wk5	Lecture 7	Validation, Verification & Testing	Chp.17	JvM	30.May.2018 Wednesday 15:45 - 17:30 (7+8)	TRAVERSE DORGELOZAAL
		No lecture in 1 June			No lecture in 1 June
Wk6	Lecture 8	Requirements Engr. for Market Driven Software	<additional reading indicated in the handout>	BÖ	06.June.2018 Wednesday 15:45 - 17:30 (7+8)	TRAVERSE DORGELOZAAL
	Deadline: AssgC- Software Requirements Specification				08.June.2018 Friday 17:30
Wk7	Lecture 9	Requirements Management and Wrap-up	Chp.27	OT	13.June.2018 Wednesday 15:45 - 17:30 (7+8)	TRAVERSE DORGELOZAAL
	Deadline: AssgD- Requirements Review Document				15.June.2018  Friday 17:30
	Final examination				28.June.2018  13:30 - 16:30
	Retake examination				16.Aug.2018  09:00 - 11:00

 

6. Course Assessment

The overall end-result of a student for this course will be based on the combination of the scores from the following components:

• Written examination: 50%
• Assignment: 50%

The written examinations focus on the content of the lecture handouts (including related chapters covered in the book) and eventually additional material (papers, etc.) presented/given as parts of the lectures. (Check here for  sample questions)
(Please note that, as the written exam is only a part of the overall grade, its validity will be limited to one year. Partial results cannot be carried over to next year. This holds also for the grades from the assignments.) 

The students should score 5.5 or above from the final examination to pass the course regardless of their assignment grade

7. Assignment

7.1. Introduction

Do you have a brilliant idea of a software application that can change the world? A perfect business model that needs a software system to make it happen?  Then, start here and now! 

The assignment involves the development (and review) of the requirements of a software application/system. The objective is to provide a practical setting for the student groups to apply the theoretical concepts discussed during the lectures and to let them face some of the challenges that are encountered in business analysis/requirements engineering in order to achieve a more thorough understanding of the theory presented in the first part of the course. To achieve this, students will:

• Develop business, user and software requirements for a part of a software application/system, and
• Review the documents as developed by another team of students.

The knowledge required to perform the assignment will be discussed during the plenary component; the lectures will be aligned with the deadlines set, enabling you to immediately apply the theory in practice. Doing the work in this order also helps you achieve a better understanding of the theory, which should support you in preparing for the written examination.

And who knows... you can consider continuing with your idea and change the world indeed! 

7.2. Scope and Content

Developing a complete requirements document for even a small realistic application / software system is a significant work, requiring more effort than is available within this course. We will therefore limit the scope of the assignment in a number of ways, so as to end up with a manageable amount of work while at the same time achieving the learning objectives of the assignment. 

• You may select any type of software application/system (web based e-commerce application, a mobile application, or ... even an existing system would be fine)
• Requirements development with real stakeholders is usually complex to organize. So, students are not expected to conduct elicitation sessions with real stakeholders. But if you do so, that would be a plus!
• For this application / software system, you will select a coherent group of use cases to narrow the scope. The suggestion is to keep it just sufficiently complex (e.g. in the order of these examples: flight booking, hotel reservation, online goods ordering, cart management and paying in online shopping, etc.).
• After the assessment of Assg.A, your group will be provided feedback - if deemed necessary- about the appropriateness of the scope; i.e. whether there is a need to extend/narrow the scope.

Despite these reductions in scope, a sufficient degree of complexity will remain to provide a satisfactory learning experience.  
There are four components in the assignment (AssgA, B, C and D), as discussed in the next section.

7.2       Assignment Components

As mentioned, the assignment has four components:

• AssgA: Vision and Scope Document               (12% of the overall grade)
• AssgB: Vision and Scope Review Document    (4% ...)
• AssgC: Software Requirements Specification  (28% …)
• AssgD: Requirements Review Document        (6% …)

AssgA: Vision and Scope Document: You will document the business requirements in a “Vision and Scope Document”, which acts as a single deliverable that sets the stage for the subsequent development work. For this document, you will consider the entire software application/system (or a considerably large component, e.g. covering 8-10 use cases) as your scope (later deliverable will narrow that to few use cases as mentioned above). A template document and example is provided. The document should (preferably) not exceed 10 pages. 

AssgB: Vision and Scope Review Document: In this part, you will review a Vision and Scope Document submitted by another student group, and document your results using the review log template provided. 

AssgC: Software Requirements Specification (SRS): You will specify the requirements of a part of the software application/system (a coherent group of use cases) in an SRS. The SRS states the functions and capabilities that a software application/system must provide, its characteristics, and the constraints that it must respect. It describes as completely as necessary the software system’s behaviors under various conditions, as well as desired system qualities such as performance, security, and usability. The SRS is the basis for subsequent project planning, design, and coding, as well as the foundation for system testing and user documentation. Similar to previous assignment component, you are expected to follow a template document, which is available together with an example.

AssgD: Requirements Review Document: In the final part, you will review an SRS developed by another student group and document your results in accordance with the template provided. In addition, there is a guiding document presenting the criteria to be used in reporting reviews.

For each of the assignment component, a template, examples and guiding documents are available in CANVAS. (Note that the documents provided as examples are not necessarily complete.)

The documents will be submitted to group folders in CANVAS. They will be assessed based on their completeness and correctness (with regard to the template and scope), consistency, and overall structure and presentation quality.