You are now studying Software Requirements Engineering. If you want to have another introductory lecture to review what you have learned, check this out:
* Introduction to Software Requirements (by Catherine Connor)
This is a good presentation that introduces Software Requirements. The author is with the Rational Software of IBM Software Group and a worldwide technical marketing and requirements specialist.
To learn more concrete and practical about software requirements, one good way is to experience with some requirements management tools. The following two websites have good suverys on Requirements Management tools.
* Requirements Management Tools: It provides a list of 42 requirements management tools.
* NCOSE Requirements Management (RM) Tools Survey: The International Council on Systems Engineering (INCOSE) publishes a comparison of features of many RM tools.
In this tutorial, we will look at and play with some requirements management tools. We will review some important concepts about software requirements throughout the tutorial.
The following lists a few of tools that I want to take a closer look:
OSRMT
Contour
SoftREQ
Comments Off
In this tutorial, we will do some tutorial exercises on requirements elicitation.
In the first part, we will look at a case study about electronic diary. We’ll then discuss the functional requirements and non-functional requirements. We’ll also discuss ambiguities and omissions in the requirements and how to improve them.
In the second part, we will use an insurance subsystem to study how to identify actors and use cases. We will also study how to draw a use case diagram based on the given information.
Comments Off
Requirements engineering is the foundation of all other software engineering activities. If we don’t have a clear understanding of a client’s requirements, we could develop a system on time and within budget, but the system does not possess the features the client needs. A small mistake made in the requirements activity is more costly than a mistake in other software engineering activities.
In this lecture, we will discuss requirements elicitation, the first part of requirement engineering. Requirements elicitation is about bringing out the requirements that originally reside in people’s minds.
Your actions before next class: Read Chapter 4 Requirements Elicitation of the textbook.
1 Comment
You will present your project proposal to the whole class. Each team has 20 minutes. I will then give you my thoughts after your presentation.
Update 1: Class 2 has finished the presentation. There are six project teams. They are Captain KFC (5), CCW (5), CFHC (3), FIVEL (5), GP2A (5), and Passcode (4). Thanks for your participation.
Update 2: Class 3 has finished the presentation. There are eight project teams. They are Darth Vader (4), F1 (5), Fall Sea (4), Passover (3), Space (4), Silent Witness (4), Time (3), and Y Man (2). Thanks for your great presentation.
Update 3: Class 1 has also finished the presentation. There are nine project teams. They are Fusion (5), LCSD (5), Doo it right (4), Click (5), CPT (4), Lamsoft (4), APEX Corporation (4), ABC (2), and Discovery City (4). Thanks for your great presentation.
2 Comments
To Group 2 students:
The tutorial on 24-Oct-2006 (Tuesday) at B0413 will be rescheduled to 26-Oct-2006 (Thursday) at B0416 at the same time slot (10:00-13:00).
I am sorry for any inconvenience thus caused.
Comments Off
In this lecture, we will continue to learn UML modeling. We will have a look at the other three fundamental notations of UML: interaction diagrams, statechart diagrams, and activity diagrams.
Here is a short summary of what you have learned in Lecture#3 and Lecture#4.
- Use case diagrams: Represent the functionality of the system from a user’s point of view;
- Class diagrams: Represents the structure of a system in terms of objects, their attributes, and relationships;
- Interaction diagrams: Represent the system’s behavior in terms of interactions among a set of objects;
- Statechart diagrams: Represent the behavior of nontrivial objects;
- Activity diagrams: Flow diagrams used to represent the data flow or the control flow through a system.
Your actions before next class: Review Chapter 2 Modeling with UML of the textbook.
1 Comment