Showing posts with label Requirements. Show all posts
Showing posts with label Requirements. Show all posts

Thursday, February 22, 2007

Simple isn't simple

This post is about John Maeda's book, The Laws of Simplicity. I just finished reading it and was simply impressed. If you read the reviews on amazon, they are mixed. I have a simpler take, read it and judge for yourself. It is a bit over $10 and 100 pages. At most it will take you the equivalent of 3 episodes of 24 to read and you will learn so much more.



I liked it a lot, will require it in many of my courses (HCI and Software Architecture and Design) and willl have several future posts on it. I have espoused simplicity and know simple isn't simple, but Maeda helps us in its pursuit. Software folks and engineers need more grounding (fore and back) in design concepts and this is a simple, gentle introduction. It is well written.



It seems appropriate to make this first post simple. For more information, Maeda has a web site. Later!



Tuesday, October 4, 2005

Mentalists need not apply

Satish Moorthy from Penn has recommended a great article by Karl Weigers, titled, "When telepathy won't do: Requirements engineering key practices."  You can access it here.  Although written specifically for folks using Object Oriented methodology, any project can benefit from it.  As an added bonus, Karl mentions some of the more popular requirements management tools.  Definitely worth a read.



Since Barry Boehm has remarked that as much as 40% of the requirements of the final product go unstated in the requirements specification, the more wisdom on this topic the better.  Thanks Satish.



Hopefully October will be a more active month for this blog than September, actually it already is since one is better than none!  I have a fairly large queue of potential entries and hope to make progress on the backlog this month so stay tuned.  Later.



Monday, September 27, 2004

Useful Use Cases

Requirements elicitation and representation is always difficult, especially when the results need to be understood by two potentially diverse populations: the stakeholders (users, management, customers, ...) and the architects, designers and developers of the system. Use cases, emphasizing scenarios, are a great middle ground for representing large hunks of the requirements in a style that is both understandable to the stakeholders and specific enough for the technical community charged with architecting, designing and implementing them.



Use cases were introduced by Ivar Jacobson in his book, Object-Oriented Software Engineering: A Use Case Driven Approach, ISBN:0201544350. However, if you are not ready to purchase the book for $60, a great free resource on Use Cases is Rebecca Wirfs-Brock's OOPSLA 2002 tutorial, The Art of Writing Use Cases. You can download a copy of it here. Wirfs-Brock's site is an excellent resource for many OO requirements, design and architecture topics. Definitely worth browsing.



If any one has had experience using Use Cases or knows of further resources, I would appreciate it if you would add a comment. Later.



Monday, May 10, 2004

On Performance

After an inter semester hiatus, this blog should show activity again. This post is again from one of the logbook entries of a student last semester, Aagmik Parikh, and is being posted with his permission. It deals with computational and theatrical performance (see my slashed. "//" comments at the end of the posting). I offer it because there does not seem to be enough attention given to performance in the early stages of a project yet there are many instances where we still hit the wall on performance.



Even when performance is considered, the assumption is that the user will upgrade to match the needs of the software. For esoteric applications that is reasonable but it should be the exception not the rule. An extreme example of this cavalier approach to cycles is the rumored requirements of Microsoft's next generation operating system codenamed "Longhorn." According to slashdot,

Longhorn will require dual 4-6Ghz processors, 2 Gigabytes of RAM, new graphics processors, a Terabyte of disk and an extremely fast network. Be prepared to upgrade even your newest PC in a few years if you would like to keep up to the latest Microsoft operating system. I hope the rumor turns out to be unfounded. We need to stop the disposable computer attitude, regardless of the price drops. New PCs cause lost productivity during the transition (not to mention the costs of transition), the old PCs choke landfills and expenditure for supporting software tax corporate budgets. At the very least we should all petition for upgradeable machines! Flame off! Enjoy Aagmik's excellent and entertaining post. Later!





A true Masterpiece .....Lord of the Rings…….making of Gollum



This week we were shown a video of the making of the Lord of the Rings, emphasizing creation of the character Gollum. There are no doubts that the digital team involved broke all barriers in CG, but the creation of this character was really interesting. Initially they had implemented a methodology called key frame animation for creation of this character. I don’t want to go to the detail of the working of this method , but in short it revolves around the making an initial frame based on a model of the character and then working on the frame to produce motion. But with the talent of the actor Andy Serkis (voice of Gollum), and the digital team they redesigned the whole project to produce a new version , which became a spectacular hit. In their new approach they used Andy’s motion capture (another method used in animation) to produce Gollum’s movements. Hence their new approach used key frame animation along with motion capture. This concept was implemented for the first time and it became an instant success.



Analyzing their work, the first think that comes to mind is….anything for performance!!. In fact I am sure their animation success is going to be a benchmark for others. They redesigned their whole approach to strive ultimate performance. It can be also related to prototyping and throw away prototyping. Their initial model lacked the energy and performance present in their later models. I also think that this is a classic example of Business Process Redesign (BPR) as they redesigned the whole process, making changes in their approach.



//I do not know if it was Business Process Redesign as much as it was technical process redesign. They really did do a great job. It is interesting that you mention performance since performance in this instance takes on two meanings: the theatrical performance which was enhanced by th emotion capture and the skill of the actor and the animation performance/speed which was enhanced by their technology. When we build systems we do not pay enough attention to either brand of performance --- our systems are in front of an audience “our users” all the time.



Wednesday, January 14, 2004

Requirements Innovation

Has innovation in requirements kept pace with innovation software process, design, analysis or even testing? I do not think so. Sure there is some innovation in requirements elicitation, especially with the use of prototyping, the Delphi method, ... but I see very little innovation in requirements presentation and use. In this age of hypertext and graphics I would expect more in presentation. Similarly in use, about the only thing I can point to is Parnas' active reviews (In D.M. Hoffman and D.M. Weiss Software Fundamentals: Collected Papers by David L. Parnas, Addison-Wesley, 2001, ISBN: 0-201-70369-6, Chapter 17. -- if you do not have this book and you are or aspire to be a software engineer, you should put it on your "books to read list", if not "books to purchase when I have enough money" list.).



Granted that life cycle tools have integrated requirements into their workbenches but there is no scheme for the rest of us.



I hope to make this one of the tracks we explore on the blog. We spend so much time grappling with and relying on requirements, yet we do not seem to spend enough time trying to improve them and their use.



So, for discussion, am I wrong? Is there innovation in requirements presentation and use, and if so where? If there is not innovation in requirements presentation and use, where should we begin? Perhaps one place to begin is to suggest publicly available instances of what you consider great requirements or attempts to be innovative in representing and using requirements. I will try to do the same. Later.