Parking system changes

Requirements 1–5 are deleted.

New requirements:

9. The machine shall make it possible to print an unpaid ticket.

10. Each ticket shall have an unique ID number.

11. For each ticket, a piece of paper shall be printed with a phone number and SMS text used to charge the ticket or get information.

12. Whenever a SMS with valid recharge text is received, the corresponding ticket shall be extended by a pre-set amount of time.

13. When there is less than ten minutes remaining on a ticket, an informational SMS shall be sent to the phone number last used to recharge the ticket, if any.

14. It shall take less than one minute to print a ticket and pay it using SMS for 95% of users who are not familiar with the system.

                    6  7  8  9 10 11 12 13 14
Relative benefit    2  9  3  7  6  6  6  3  4
Penalty if missing  1  6  3  7  8  6  9  1  5
Cost of implement.  1  7  6  4  4  1  7  4  7
PRIORITY            2  8  0 10 10 11  8  0  2

Task 2:
                    6  7  8  9 10 11 12 13 14
Complete            -  -  -  -  -  -  -  -  -
Traceable           Y  Y  Y  Y  Y  Y  Y  Y  Y
Testable            Y  N  Y  Y  Y  Y  Y  Y  Y
Consistent          Y  Y  Y  Y  Y  Y  Y  Y  Y
Feasible            Y  Y  Y  Y  Y  Y  Y  Y  Y
Uniq.Determined     Y  Y  Y  Y  Y  Y  Y  Y  Y
Design Free         Y  Y  Y  Y  Y  Y  Y  Y  Y
“Shall”             N  Y  N  Y  Y  Y  Y  Y  Y

Parking system SRS & Evaluation

1. The system shall accept 90% of valid 10¢, 20¢, 50¢, 1€, 2€ coins. (This requirement may change in the future; it is essential)
2. The system shall reject 99.9% of other coins used in the world. (This requirement is stable and essential)
3. If the user has, in one transaction, put in coins whose value exceeds the cost of the ticket, the system shall print out the ticket and return the difference in smaller coins. (This requirement is stable and essential)
4. If enough smaller coins are not available to return the difference, an error message shall be displayed and all coins from the current transaction shall be returned to the user. (This requirement may change in the future and essential)
5. Unless a ticket has already been printed out, the system shall return all money from the current transaction when the CANCEL button is pressed. (This requirement is stable and essential)
6. All error messages shall display a service telephone number. (This requirement may change in the future, it is conditional)
7. The system shall accept all major credit cards. (This requirement is stable and essential)
8. The operating company shall be able to deactivate or activate all its machines, or a specific subset, remotely. (This requirement is stable and conditional)

   Corr. Unambig. Compl. Cons. Ranked Ver. Mod. Tr.

1. Yes   Yes      -      Yes   Yes    Yes  Yes  Yes

2. Yes   Yes      -      Yes   Yes    Yes  Yes  Yes

3. Yes   Yes      -      Yes   Yes    Yes  Yes  Yes

4. Yes   Yes      -      Yes   Yes    Yes  Yes  Yes

5. Yes   Yes      -      Yes   Yes    Yes  Yes  Yes

6. Yes   Yes      -      Yes   Yes    Yes  Yes  Yes

7. Yes   No       -      Yes   Yes    No   Yes  Yes

8. Yes   Yes      -      Yes   Yes    Yes  Yes  Yes

-----------------------------------------------------

*  Yes            No     Yes               No

*) Whole document

Cor. = Correct

Unambig. = Unambiguous

Compl. = Complete

This SRS far from complete. Much more work is needed for additional requirements.

Cons. = Consistent

This SRS is internally consistent; it would also needs to agree with higher-level documents.

Ranked = Ranked for importance/stability

Ver. = Verifiable

All requirements except 7 are verifiable.

Mod. = Modifiable

The SRS does not have an organization; however, it is not redundant and itemizes requirements well.

Tr. = Traceable

Each requirement has a number for forward traceability, backwards traceability is not an issue since this is the first version.

Extreme Chaos Report – answers to questions

What are the trends in the failure/success/challenged projects?

Overall, the number of successful projects is rising. The ratio of challenged projects is also rising, and the ratio of failed ones is decreasing.

Also, the average project size is decreasing, which may be the primary cause of these good results.

What are the reasons for past projects to be success and what are main reasons for failure?

The main reason for project success is executive support, which has become the most important only recently. Other reasons are user involvement, an experienced project manager, clear business objectives and minimized scope.

The reasons for failure is, generally, the lack of these.

What are the suggested recipes for success according to the report (see also last page)?

A small project has the best chance of being successful. The CHAOS recipe recommends no more than 4 people, at most 4 months of time, and less than $500000 (about ⅓ million €) in budget.

Compare the previous answer with the recipe from 1994: http://standishgroup.com/sample_research/chaos_1994_4.php. What are the differences? Can you explain them?

Aside from the difference in writing style, the newer report is much more specific – it gives actual numbers instead of vague terms. This is understandable, since there is more research data now.

The old “recipe” instruct to release early and often, to break the project into smaller pieces. The new recipe just calls for smaller projects. The report says (near the end of page 4) that “the act of minimizing scope leads to greater success than that of creating smaller milestones”. This is probably a result of more data as well.

The last difference is that the old recipe mentions that project managers should learn from their mistakes and bad luck. This is missing from the newer version, either because the Standish Group didn't have enough data to support it, or just because they didn't find a good cooking pun to go with it.

What skills a project manager should have? How do you judge your skills if you were assigned to such a task?

• Business skills. Here, I would fail. I do not have business skills.
• Technical skills. I can safely say my technical skills are good enough for leading a big project.
• Project management skills. I have some experience with project management, but I definitely need more. That is partly the reason why I am taking this course.
• Decision skills. I am able to make firm decisions if I am given authority.
• Process skills. I do not have experience in this field, although I plan to improve this.
• Detail skills.This is my strong point; I have no problems thinking about both the big picture and details.
• Organization skills. In school projects, I tend to lead and organize work. I would say my organization skills are above average.
• Communication skills. I'm average in this regard.

SRS Documents

Document 1. ProcessImpact SRS template

http://www.processimpact.com/process_assets/srs_template.doc

(HTML version from Google: http://209.85.135.132/search?q=cache:8fmA-O1OsYcJ:www.processimpact.com/process_assets/srs_template.doc+software+requirements+specification&cd=3&hl=en&ct=clnk&gl=fi)

Document 2. ACIS SRS (complete document)

http://acis.mit.edu/acis/sreq/sreq.book.html

Structure

All documents are structured clearly and hierarchically.

The IEEE and ACIS documents have more structural levels than the ProcessImpact template. This may be due to their size.

Contents

The three documents are of different kinds: the IEEE one gives guidelines for requirements specification,

ProcessImpact gives a template for such a specification, and ACIS has a full specification document for a complicated system.

The IEEE guidelines has the richest structure, featuring an abstract, keywords, an introduction, table of contents and appendices, in addition to the main text.

It also includes a template. The ACIS document generally follows this template (specifically, the variant in A.5), although it leaves out or adds some sections.

The

ProcessImpact template is organized quite differently.

The template does not give clear, concrete descriptions of what should be written, nor a rationale for why it is needed. However,

it has sections relating to the evolution of the document: the Revision History and Issues List sections. (IEEE mentions a “formal change process” and suggests an audit of changes should be provided, but does not include this in its template.)

The ACIS document has only the requirements themselves. The requirements are not ranked for importance/stability, but the ones that are not essential are listed in an appendix. The requirements I have looked at are unambiguous, verifiable, modifiable and traceable as per IEEE guidelines. (Checking if they are correct, complete or consistent would require analyzing the whole document, which I did not do.)

Style

The IEEE and ACIS are written in scientific style, which reinforces the fact that they are well thought-out and formalized. The

ProcessImpact template is written in a more general language, in the imperative mood.

Requirements Management - literature survey preparation

OUTLINE
- Introduction
- Definition and Context
- Why RM is Needed
- RM Methods
- RM Metrics
- Conclusion

REFERENCES
[1] R. H. Thayer and M. Dorfman, Eds., Software Requirements Engineering,
2nd ed. Los Alamitos, CA: IEEE Computer Society Press, 1997.

[2] U. Nikula, “Introducing basic systematic requirements engineering practices in small organizations with an easy to adopt method,” p. 207, 2004.

[3] L. Goldin and A. Finkelstein, “Abstraction-based requirements management,” in Proceedings of the 2006 international workshop on Role of
abstraction in software engineering. New York, NY, USA: Association
for Computing Machinery, 2006, pp. 3–10.

[4] B. Nuseibeh and S. Easterbrook, “Requirements engineering: a roadmap,”
in ICSE ’00: Proceedings of the Conference on The Future of Software
Engineering. New York, NY, USA: ACM, 2000, pp. 35–46.

[5] P. Hantos, “A systems engineering view of requirements management
for software-intensive systems,” in ICSE ’99: Proceedings of the 21st
international conference on Software engineering. New York, NY, USA:
ACM, 1999, pp. 620–621.

[6] M. C. Paulik, B. Cutis, M. B. Chrissis, and C. V. Weber, “Capability
maturity model for software, version 1.1,” 1993.

[7] K. Reed, E. Damiani, G. Gianini, and A. Colombo, “Agile management of
uncertain requirements via generalizations: a case study,” in QUTE-SWAP
’04: Proceedings of the 2004 workshop on Quantitative techniques for
software agile process. New York, NY, USA: ACM, 2004, pp. 40–45.