Updated 2023-01-31: New:
The mini-course in user interface design had wrong links to the slide show. Now corrected: Mini-course.
Soren has changed mail address to: slauesen@os.dk
Several pdf-files had strange meta-data, making some pdf-viewers show strange document names. Now corrected.
The section on the User story experiment has been improved.
The report on project failures and cures is available here:
Download latest report (pdf)
Download latest overview of failure data (xlsx) And in Danish: Seneste oversigt (på dansk) (xlsx)
|
Home Søren Lauesen, professor emeritus Nordtoftevej 15 DK-2860 Søborg Phone +45 3956 1748 Mobile +45 2963 6248 Email: slauesen@os.dk Web: www.itu.dk/people/slauesen/ |
Affiliation IT University of Copenhagen Rued Langgaards Vej 7 DK-2300 Copenhagen S Phone, main: +45 7218 5000 |
About SorenProject CV (pdf) CV and interests Publication listProject failures and curesLarge IT projects may be damaged in many ways, for instance large cost or schedule overruns, unsatisfied users, or disappointing business results. I have investigated several large projects and identified 37 damage causes and 22 cures. The full report (pdf). The short version published in IEEE Access, 2020: Soren Lauesen: IT Project Failures, Causes and Cures (pdf).Related data: Overview of failure data (xlsx), and in Danish: Oversigt (på dansk) (xlsx)
Want help to write problem-oriented requirements? Simply send a message to: slauesen@os.dk Problem-oriented requirements - SL-07 Danish versionTraditional requirements describe what the system shall do. Problem-oriented requirements (SL-07 requirements) describe what the system is to be used for. They cover all kinds of requirememts, are five times shorter, five times faster to write, and five times faster to reply to. Y-Foundation requirements CMS requirements Use cases vs. SL-07 tasks Textbook and papersUser story experimentMy colleagues in industry and universities praise user stories and epics, as the way to write requirements. But there is no agreement on how to use them and how they cover requirements. The inventors of "user stories" were academics, who had tried them on toy systems with students.In cooperation with Mohammad Kuhail, I compared 8 requirements specifications written by 8 professional analysts for the same real-life project: A support system for a hotline. The analysts had got an analysis report mentioning 30 functional issues the customer wanted the system to deal with. They could use user stories and whatever else they found needed. They could ask us questions, as they could do in a real project, but nobody did. In their replies, they used user stories and epics only. We asked the analysts whether they covered all requirements and to our surprise, they all said "yes". However, on average, their specifications covered only 10 of the 30 functional issues the customer had stated (ranging between 5 and 13 issues). Further, user stories hardly mentioned any of the non-functional requirements needed too, such as usability, data migration and phasing out. Many user stories were wrong: they specified something the customer definitely didn't want. See more IT Contracts for IT people (in Danish)Requirements are often appendices to long contracts. IT-people don't read the contract and lawyers don't read the requirements. It need not be so. SL-07 requirements have an 8 page contract with 4 appendices. Together they cover what traditional 50 page contracts with 16 appendices do.UX versus User Interface DesignThere is a big gap between UX specialists and software developers. UX specialists are good at identifying user needs and testing whether usability of the user interface is adequate. However, they are rarely able to design intuitive and efficient user interfaces. Nor are programmers. There are no systematic design methods. At best it is trial-and-error. Around 2005, Lauesen invented a design method (Virtual Windows) that gives a minimum of user screens, good data overview, efficiency for professional users, and fast development. The health record screen at the right was developed with this method. Mini-course in the method Some great user interfaces Microsoft Access tutorial Other UX papersData visualization, End-user development and EHRProfessionals need overview of complex data, so good data visualization is crucial. Uvis is a tool that allows IT-interested users to develop interactive, complex data visualizations. The health record screen at the right was made this way. Visualization papersEHR - Electronic health recordsLauesen has been involved in many aspects of EHR. Here are some links: The early national EHR strategy Graphical and customizable EHR Anonymizing an EHR Troubles with the EPIC acquisition Time study of EPIC in the clinicIT architecture and software engineering (in Danish)Lauesen has worked in software engineering since 1962. He wrote his first tutorial in 1969, developed operating systems, studied why SW research wasn't used in industry, how perfectionism killed usefulness, and fought hype about OO, SOA and IT-architecture. |
One of my interests Guide to SL-07 Uvis health record User interface design |
