jump to navigation

Boston Project Manager, Paul Seibert April 24, 2013

Posted by HubTechInsider in Uncategorized.
Tags: , , , ,
add a comment

Boston Project Manager, Paul Seibert

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. I have been working in the software engineering and ecommerce industries for over fifteen years. My interests include computers, electronics, robotics and programmable microcontrollers, and I am an avid outdoorsman and guitar player. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a PMO Director, a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which is Tshirtnow.net.

What are some good books on User Interface design? How do you define user interfaces in your software specification documents? The Hub Tech Insider User Interface Design Bookshelf July 31, 2011

Posted by HubTechInsider in Agile Software Development, Ecommerce, Mobile Software Applications, Product Management, Project Management, Social Media, Software, Uncategorized.
Tags: , , , , , , , , , ,
add a comment
Screenshot of Glade Interface Designer

Image via Wikipedia

The Hub Tech Insider User Interface Design Bookshelf: Essential UI Design Books for IT Directors, Project Managers, Program Managers, Software Requirements Engineers, Business Analysts, User Interface Designers, Graphic Designers, Interaction Designers and Information Architects.

Some of the tools that I typically use to produce wireframes and mockups to specify software that is under development include traditional desktop personal computer graphics application software packages such as Adobe Illustrator and Photoshop, business graphics and diagramming packages such as Microsoft Visio, and many others, including some on the Mac OS X and Linux platforms.

But no matter which software program you use to prepare your wireframes and mockups, you still need to have the knowledge surrounding what types of controls are available, and the wisdom to know the most apropos situations in which to use those software controls.

It may be surprising to many people that are not involved in the software industry, but it is not always system and application software programmers who are the most familiar with these types of user interface interactivity patterns and controls. User interface designers, graphic designers, and information and interaction architects are usually the ones who specify these types of “Web 2.0” controls.

If you are writing software specification documents, I recommend that you become as familiar as possible with all of the different types of rich internet application controls and interaction patterns that are examined in detail within these books. Programmers and project and program managers will benefit as well.

A great amount of time and effort will be saved if everyone on the project team has familiarity with these fundamental web interface and interaction patterns. Having a common vocabulary with which to communicate to each other in design and development meetings will pay dividends throughout the course of the software development lifecycle.

The ability to suggest an interaction pattern or a type of control that can preserve screen or page real estate, for instance, can make the critical difference in getting a software system design specified in a limited amount of time. Having knowledge of user interface best practices and common user interaction patterns in-house, on the project team itself, can not only save money in avoidance of expensive user interface consultants and UI design firms, but it can also ensure that the tricky question of post-implementation compliance amongst your development team and programming staff.

I have compiled a list of books that in my opinion merit a place on any professional user interface designer’s bookshelf. If you are looking to stock your User Interface library, you really can’t go wrong with this list of books.

I feel that IT Directors, Product Managers, Program Managers and Project Managers, as well as Graphic Designers, Information Architects, and Interaction Designers and Usability Engineers (read this article if you need help understanding what these job titles mean) could all benefit from reading several or all of these books.

I have found in my professional career that having advanced knowledge of User Interface design techniques and best practices aids me greatly in producing high quality project plans and functional specifications for web based applications and their related software development projects. Mockups and wireframes that incorporate the various design patterns outlined in these books have greatly increased my ability to communicate and develop project related deliverables and artifacts for complex and cutting edge user interfaces, particularly those that include social media platform integrations and RIA, or Rich Internet Application, frontends.

The more knowledge that you acquire in your professional career on a software development team, and the more you know about user interfaces for web based applications, the more value you will be capable of delivering to both your employer and yourself in the form of expanded career opportunities.

Web Form Design: Filling in the Blanks

By Luke Wroblewski. Rosenfeld Media, May 2008.

Web Form Design: Filling in the blanks, by Luke Wroblewski

Anyone who designs anything for the web needs a copy of this. It makes it so nice to not have to think about designing forms. I can spend my time on more interesting design challenges. This book doesn’t leave my desk.

Forms make or break the most crucial online interactions: checkout, registration, and any task requiring information entry. In this book, Luke Wroblewski draws on original research, his considerable experience at Yahoo! and eBay, and the perspectives of many of the field’s leading designers to show you everything you need to know about designing effective and engaging web forms.

I have found this book to be the most practical, comprehensive and data-driven guide for solving form design challenges and I consider it an essential reference.

The Smashing Book #1

https://shop.smashingmagazine.com/smashing-book-intl.html

The Smashing Book #1

This book is available exclusively from Smashing Magazine. This book looks at Web design rules of thumb, color theory, usability guidelines, user interface design, best coding and optimization practices, as well as typography, marketing, branding and exclusive insights from top designers across the globe.

This book contains ten carefully prepared, written and edited stories that are based upon topic suggestions and wishes of Smashing Magazine’s readers. The topics covered here are fundamental and so the content is highly practical.

The Smashing Book #2

https://shop.smashingmagazine.com/smashing-book-2-intl.html#d=smashing-book-2

The Smashing Book #2

This book shares valuable practical insight into design, usability and coding. It provides professional advice for designing mobile applications and building successful e-commerce websites, and it explains common coding mistakes and how to avoid them. You’ll explore the principles of professional design thinking and graphic design and learn how to apply psychology and game theory to create engaging user experiences.

Designing Web Interfaces: Principles and Patterns for Rich Interactions

By Bill Scott & Theresa Neil

http://www.amazon.com/gp/product/0596516258?ie=UTF8&tag=looksgoodwork-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0596516258

Want to learn how to create great user experiences on today’s web? In this book, UI experts Bill Scott and Theresa Neil present more than 75 design patterns for building great web interfaces that provide interaction. Distilled from the author’s years of experience at Sabre, Yahoo!, and Netflix, these best practices are grouped into six key principles to help you take advantage of the web technologies available today. With an entire section devoted to each design principle, Designing Web Interfaces illustrates many patterns with full-color examples from working websites. If you need to build or renovate a website to be truly interactive, this book will give you the principles for success.

Don’t Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition

by Steve Krug

http://www.amazon.com/Dont-Make-Me-Think-Usability/dp/0321344758/ref=pd_bxgy_b_img_c

Five years and more than 100,000 copies after it was first published, it is very difficult to imagine anyone working in web development or design that has not read this classic on web usability, but people are still discovering it every day. In this second edition, Steve adds three new chapters in the same style as the original: wry and entertaining, yet loaded with insights and practical advice for novice and veteran alike. Don’t be surprised if it completely changes the way you think about web design.

The three new chapters are entitled: Usability as common courtesy (why people really leave web sites), Web accessibility, CSS, and you (making sites usable and accessible), and Help! My boss wants me to ______. (Surviving executive design whims).

In this second edition, Steve adds essential ammunition for those whose bosses, clients, stakeholders, and marketing managers insist on doing the wrong thing. If you design, write, program, own, or manage web sites, you must read this book.

Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems

http://www.amazon.com/Rocket-Surgery-Made-Easy-Yourself/dp/0321657292/ref=pd_bxgy_b_img_b

It’s been known for years that usability testing can dramatically improve products. But with a typical price tag of $5,000 to $10,000 for a usability consultant to conduct each round of tests, it rarely happens.

In this how-to companion to Don’t Make Me Think: A Common Sense Approach to Web Usability, Steve Krug spells out an approach to usability testing that anyone can easily apply to their own web site, application, or other product. (As he said in Don’t Make Me Think, “It’s not rocket surgery”.)

Information Architecture for the World Wide Web: Designing Large-Scale Web Sites

http://www.amazon.com/Information-Architecture-World-Wide-Web/dp/0596527349/ref=pd_sim_b_2

Saul Wurman first used the term Information Architecture in his book of the same name. His book was mostly lots of really pretty pictures of media and webs compiled from a graphic design perspective; they were beautiful but never really dealt with the information end of things. Rosenfeld and Morville get it right. They show how to design manageable sites right the first time, sites built for growth. They discuss ideas of organization, navigation, labeling, searching, research, and conceptual design. This is almost common sense, which is often overlooked in the rush for cascading style sheets and XML.

The Elements of User Experience: User-Centered Design for the Web

http://www.amazon.com/Elements-User-Experience-User-Centered-Design/dp/0735712026/ref=pd_sim_b_5

From the moment it was published almost ten years ago, Elements of User Experience became a vital reference for web and interaction designers the world over, and has come to define the core principles of the practice. Now, in this updated, expanded, and full-color new edition, Jesse James Garrett has refined his thinking about the Web, going beyond the desktop to include information that also applies to the sudden proliferation of mobile devices and applications.

Successful interaction design requires more than just creating clean code and sharp graphics. You must also fulfill your strategic objectives while meeting the needs of your users. Even the best content and the most sophisticated technology won’t help you balance those goals without a cohesive, consistent user experience to support it.

With so many issues involved—usability, brand identity, information architecture, interaction design— creating the user experience can be overwhelmingly complex. This new edition of The Elements of User Experience cuts through that complexity with clear explanations and vivid illustrations that focus on ideas rather than tools or techniques. Garrett gives readers the big picture of user experience development, from strategy and requirements to information architecture and visual design.

Forms that Work: Designing Web Forms for Usability

by Caroline Jarrett and Gerry Gaffney

http://www.amazon.com/Forms-that-Work-Interactive-Technologies/dp/1558607102/ref=pd_sim_b_3

Forms are everywhere on the web – used for registration and communicating, for commerce and government alike. Good forms make for happier customers, better data, and reduced support costs. Bad forms fill your organization’s databases with inaccuracies and duplicates and can cause the loss of potential or current customers. This book isn’t about just colons and choosing the right widgets. It’s about the entire process of making good forms, which has a lot more to do with making sure you’re asking the right questions and in such a way that your users can answer than it does with whether you use a drop-down list or radio buttons.

If your web site includes forms, then you need to read this book. In an easy-to-red format with lots of examples, Caroline Jarrett, who runs the usability consulting company Effortmark Ltd.(http://www.usabilitynews.com), and Gerry Gaffney, who runs the usability consulting company Information & Design Proprietary Ltd.(http://www.uxpod.com), present their three layer model – appearance, conversation, and relationship. You need all three for a successful form – a form that looks good, flows well, asks the right questions in the right way, and most importantly, gets users to fill it out.

Designing good forms is trickier than people think. This book explains exactly how to design great forms for the web. Liberally illustrated with full-color examples, it guides readers through how to define and gather requirements to how to write questions that users will understand and want to answer, as well as how to deal with instructions, progress indicators, and error conditions.

I found that this book provides proven and practical advice that will help designers avoid pitfalls, and produce forms that are aesthetically pleasing, efficient, and cost-effective.

The book is filled with invaluable design methods and tips to help ensure accurate data and satisfied customers, and includes dozens of examples, from nitty-gritty details (label alignment, mandatory fields) to visual design (creating good grids, use of color).

Defensive Design for the Web: How to improve error messages, help, forms, and other crisis points

http://www.amazon.com/gp/product/073571410X?ie=UTF8&tag=looksgoodwork-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=073571410X

by Matthew Linderman and Jason Fried

Let the 37signals team show you the best way to prevent your customers from making mistakes, and help them recover for errors if a mistake does occur. This book doesn’t leave my desk either.

The folks at 37signals have created an invaluable resource: tons of ‘best practice’ examples for ensuring that web users can recover gracefully when things – as they inevitably will – go ‘worng’ !

In this book, you will learn 40 guidelines to prevent errors and rescue customers if a breakdown does occur. You will see hundreds of real-world examples from companies like Amazon and Google that show the right (and wrong) ways to handle crisis points.

You can also use this book to evaluate your own site’s defensive design with an easy-to-perform test and find out how to improve your site over the long term.

About Face 3: The Essentials of Interaction Design

By Alan Cooper. Wiley 2007.

About Face 3, by Alan Cooper

Learn the rules before you break them. Please. Pretty please with a cherry on top? Get this book and read it if you are responsible for designing anything more than a simple web site. Good for Flex developers and Ajax developers as well. Lots of patterns that can be extrapolated for Rich Internet Applications.

Prototyping: A Practitioner’s Guide

http://www.amazon.com/gp/product/1933820217?ie=UTF8&tag=looksgoodwork-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1933820217

Prototyping: A Practitioner’s Guide” is a terrific and comprehensive review of both the prototyping process and the tools involved. There’s really very little with which to find fault. I found that the book both validated my experience in prototyping and provided new techniques to try out, with many “Aha!” moments in both respects. The inclusion of case studies illustrating the techniques provide additional perspective and make the techniques more “real”. The review of each prototyping technique/tool, whether paper or software-based, includes links to additional resources like toolkits, sample images, and the like – these would be especially useful to someone just getting started with a particular tool. Speaking as a designer who’s typically relied on HTML prototypes and Visio, I must say my interest in Adobe Fireworks and, to a lesser extent, Axure is piqued. I think any UI/UX/IX designer, of any level of experience, would get something out of this book. Not that it would be useful only to them – analysts and software engineers will benefit from it as well.


Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. I have been working in the software engineering and ecommerce industries for over fifteen years. My interests include computers, electronics, robotics and programmable microcontrollers, and I am an avid outdoorsman and guitar player. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a Technical PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which are Twitterminers.com and Tshirtnow.net.

How do you write software requirements? What are software requirements? What is a software requirement? July 28, 2011

Posted by HubTechInsider in Project Management.
Tags: , , , , , , , ,
1 comment so far
Waterfall Model

Image via Wikipedia

What is a software requirement?

A software requirement, simply stated, is something that matters to someone who matters.

A software requirement may take the form of anything from a high-level, abstract statement of a service or constraint to a detailed, formal specification. Software requirements must serve many purposes during the software engineering process, and so this is the reason that there is so much variation in how they are written and presented.

My main approach to writing requirements can vary in format from project to project, but I tend to prepare a list of software requirements in a computer spreadsheet program like Microsoft Excel or Google Docs, or Open Office Spreadsheet. This requirements document is always dated, ranked, the source of the requirements is always noted for traceability, and it is usually accompanied and supplemented by a catalog of use cases and a functional specification document with mockups and wireframes.

What are the characteristics of good software requirements?

The IEEE has a standard, IEEE 830, that lays out the characteristics according to the IEEE of good software requirements:

1. Correct: The SRS, or software requirements specification, should correctly describe the system behavior. It is not productive to have a requirements document that describes implausible or impossible expected system behavior or user goals.

2. Unambiguous: Software requirements should be written in such a manner as they are not subject to different interpretations. The use of specific and appropriate language can help avoid ambiguity in interpretation.

3. Complete: the software requirements document should completely describe the system’s expected behaviors and feature set.

4. Consistent: Requirements for the system under discussion must not contradict each other.

5. Ranked: You must rank your software requirements for importance. Each software requirement has its own level of importance and criticality, and they are not all equal. By ranking the requirements, software designers ensure that guidance is given to the development team regarding effective prioritization.

6. Verifiable: If the requirement cannot be verified as having been met, then the requirement itself is written poorly. The requirements have to be testable.

7. Modifiable: The requirements must be easy to modify or change.

8. Traceable: The requirements must be traceable, and it is essential that traceability information has been provided, as the requirements document provides the starting point in the traceability chain. I have written elsewhere in this blog at length about the importance of software requirements traceability and have provided examples of software requirement traceability matrixes. Many software development organizations use proprietary CASE software tools and other methods to enforce traceability policies that stipulate how much traceability information regarding requirements must be maintained.

What are some wording and language best practices for software requirements?

I have many years of hard won expertise in writing software requirements. About this topic I have discovered many tips and tricks of the trade that can serve you well as excellent best practices. I suggest that you invent and use a standard format for all of your requirements and requirements documents, including use cases and functional specifications. You should take great care to use language in a consistent way when writing your software requirements.

I recommend that you use “Shall” when you are writing mandatory software requirements, such as “The system shall provide a facility for a store manager to enter an alternate shipping address onto the order confirmation page”.

I recommend that you use “Should” for desireable software requirements, such as “The system should enable the use of as many payment gateways as have been configured by engineering prior to the current release”.

Feel free to boldface or otherwise emphasize or highlight key parts of the requirement. This holds true for use cases ad functional specification documents as well.

I recommend that unless it is absolutely necessary, you should avoid technical language or implementation details in your requirements documents.

What do bad software requirements look like?

What makes software requirements “Bad” software requirements? Well, lack of specificity is one way requirements can be reckoned to be poor. Another way in which software requirements can fail to serve their purpose in the software development effort is when they are written in a way in which they are they are not verifiable. If, for instance, a software requirements engineer were to write a software requirement in which he or she stated the system under discussion was to be “completely reliable”, what exactly would they mean, and how would “reliable” be quantified? If a percentage is used in the writing of a software requirement, the whole or the baseline percentage and boundaries should be specified.

The following are some examples of very poor software requirements — you really don’t want to write software requirements which look like these, trust me:

“The system shall be completely reliable”

“The system shall be maintainable”

“Order rejections shall be less than 99%”

“The system shall be fast”

“The system should use artificial intelligence”

“The system should be totally modular”

What do good software requirements look like?

I have already mentioned IEEE standard 830, which can serve as a fundamental basis guide for you when you set out to write your own software requirements, but let me emphasize a few key points here before setting some example good software requirements before you.

Make sure that your requirements are traceable, verifiable, and specific. Ensure that when you write your software requirements that you quantify any specific qualities that you write about as desireable User goals or User Stories. Make sure you rank your requirements for software development and date them, notating the source of the requirement, the venue of the requirement’s origin, the primary internal and external stakeholders, and the DRI, or directly responsible individual, who is assigned to sheparding that requirement through development. Make sure that you use “Shall” for mandatory requirements and “Should” for optional, or “nice to have” requirements.

“The response time for the system to present the checkout page upon an order button click on a product detail page shall be less than 500ms”

“95% of all transactions on the public-facing webstore portal shall be processed in less than 4s”

“MTBF for the domain controller server shall be 5000 hours of continuous operation”

“The system shall present the closest 5 stores to the user on the map page, provided that 5 stores are within the user-defined search radius”

How do you rank software requirements?

For the most part, I generally advocate a three level rating system for software requirements: mandatory, desirable, and optional. The mandatory requirements cannot be sacrificed, desirable requirements are important but could be sacrificed if necessary to meet schedule or budgetary concerns. Optional requirements are ones which may not be developed, simply due to the fact that they have been rated as being “nice to have”.

Ranking of software requirements comes in handy when the development team needs to make tradeoffs. For example, if time or work force is limited, the development team’s focus can then be placed on the higher ranked requirements.

What is the role of the requirements document in the software development process?

The requirements document is the official statement of what is required of the system developers. The requirements document should include both a definition and a specification of requirements. However, the requirements document is not a design document. To the extent that it is possible, the requirements document should be a set of statements regarding what the system should do, not how it should do it. In the real world, the requirements document does tend to contain some design specifications, which can box in the programmers later if carried too far.

Precise software specifications provide the fundamentals for analyzing the requirements, validating that they are the stakeholder’s intentions, defining what the designers have to build, and verifying that they have done so correctly.

Requirements allow the system’s programmers and software engineers to know the motivation for development of the system under construction. Software requirements also help the engineers manage the process of evolving the software over time and across suites of related software products and web-based services.

Who typically uses software requirements documents?

There are a great variety of stakeholders, both internal and external, who utilize the requirements documents throughout a typical software development project lifecycle. Each of these stakeholders will have a different perspective on the requirements document and they will each put the requirements document to a different use:

1. Customers or clients: will desire to, as completely as possible, express how their needs can be met. They continue to do this throughout the software development lifecycle process as their perceptions of their own needs change.

2. Developers or programmers: will attempt to create a software design that will satisfy all of the requirements laid out by the system designers.

3. QA personnel and testers: will use the requirements document as a basis for writing and conducting the tests they will use to verify that the system functions as it was designed.

4. Managers and project leaders: will use the requirements document as a contract to bid upon the system and then control the production of the software throughout the software development lifecycle.

5. System and Maintenance engineers: will use the requirements document as evidence of what the designers of the system had originally intended for it to do, using this as a guide for continuing evolution and maintenance efforts.

What is software requirements engineering?

Software requirements engineering is a subset or subdiscipline of software engineering that is focused on determining and specifying the functions, constraints, and user goals of the software system being designed.

The software requirements engineering process begins with a discovery project or feasibility study which leads to a discovery project findings document or project feasability report. There are instances, rare though they may be, when a software development project feasability study will actually conclude that the best course of action for a development organization is to not move forward with the development project. Feasibility studies can help your discovery team uncover answers to questions such as these:

1. Is a new technology needed for us to develop the system under discussion? What expenses will be involved in acquiring this new technology or resources experienced in working with it?

2. What is the impact, in all aspects, of not constructing the proposed system?

3. What are the current problems the system under discussion is proposed to alleviate?

4. How will the proposed system allievated these concerns?

5. What will be some of the development and integration problems encountered by the system’s design and programming project teams?

Software requirements engineering is strongly influenced by computer science and systems engineering, however, as developing software is an art, not a science, and since developing software is a human endeavor not generally considered a “true” engineering discipline, software requirements engineering draws upon a number of different disciplines and fields of study. Particularly with respect to understanding the user goals and needs and desires of humans, individuals with a diverse background in anthropolgy, philosophy, cognitive psychology, linguistics and other liberal arts fields often make superb requirements elicitators and software requirements engineers. It is oftentimes business analysts who take the fore in requirements elicitation and gathering in many organizations.

Software requirements engineering for a software development project has a few typical phases:

1. Requirements elicitation and gathering is always a necessary step, as frequently primary internal and external project stakeholders do not know what they want, the requirements can be deeply “hidden” within a client organization, prior requirements may not be validated or verifiable, and even completely incorrect. This is the phase of the project which will largely determine the success or failure of the project.

2. Requirements modeling is a way in which the written, prose requirements are presented in another format. Although effectively doing this can prove difficult for novices, many techniques such as use case modeling, UML diagrams, user stories and user goals can help system designers and requirements engineers and business analysts represent the requirements in a more easily comprehensible or shareable form.

3. Analyzing requirements is the process whereby the requirements are checked for consistency, correctness, completeness, sufficient detail, and writing style and format.

4. Requirements change management is a requisite activity for business analysts and software requirements engineers, as requirements are changing all the time and this process is to be expected and prepared for.

What different types of software requirements are there?

Even though there are many different types of forms software requirements may take, in my own experience a requirements document may encorporate a few different types of requirements within the same document, sometimes subdivided into sections or categorized. I wanted to take some time to explain a little about each of the types of software requirements so that when you are discussing requirements with stakeholders internal and external, as well as your project team, you can more easily express what you mean in terms of what type of requirements and for what purpose you wish to write them.

There is quite a bit of overlap in the functions of each of the types of software requirements I’m about to discuss. Keep this in mind, and remember that one of the points of this excercise is to familiarize yourself with the lingo. Knowing what each of these terms for software requirements refers to can help you forget about classifying your requirements and instead focus on just getting the requirements down on paper (or rather into your computer spreadsheet program or requirements management database) quickly.

1. Functional requirements are generally written from a bird’s-eye viewpoint, or at a high level, although they can also be very detailed, and contain annotations and notes, as well as references to other materials such as screen and page mockups and flow diagrams. They can describe not only what the system under construction should do, but also what it should not do.

2. Nonfunctional requirements are boundary conditions or externalities to the system under construction which will effect the performance envelope or capabilities of the system once it is operation. These types of requirements may include things such as environmental constraints, compliance with federal and state laws or industry regulations, safety standards, timing constraints, quality or uptime properties, programming languages to be used, etc.

3. Design constraint requirements include nonfunctional requirements that relate to hardware limitations and industry standards compliance.

4. Logical database requirements include things such as required data models or database schemas, data entity relationship diagrams (ERDs) stipulating database requirements, data entities and their required relationships, data retention and data integrity constraints, as well as database requirements that specify data access frequency of use data and accessing capabilities.

5. Domain requirements are a type of nonfunctional requirement which has been dictated to the system designers by the application’s domain of operation. For example, a health care application software system may have data integrity and security domain requirements which are derived from the HIPAA health care industry standards regarding private health care information (PHI). Domain requirements may impose new functional requirements or boundary conditions on existing requirements.

6. System attribute requirements are functional requirements which include information regarding the desired system availability, reliability, maintainability, portability and security.

7. Interface specifications are yet another type of functional requirements for software systems which are defined in terms of specifying how the system should interoperate with other software systems. There are many types of formalized notation systems used to specify these types of interfaces, including UML, or unified modeling language diagrams. The interface specifications focus on defining the data entities to be exchanged with other software systems, their structures and representations, as well as defining the interfaces themselves.

7. Performance requirements quantify the desired performance of the system being constructed. Performance requirements are a type of functional requirement, and there are two major types of performance requirements, those that measure or stipulate the performance of static system objects, processes or events, and those that stipulate the performance of dynamic system objects, processes or events. Performance requirements for software system generally take the form of numerically expressed time constraints. A software system’s static performance requirements might include things such as the number of simultaneous users the system would need to support at any given moment of time, whereby a system’s dynamic performance requirements might include such constraints as the number of work orders that would need to be processed by the system within certain time periods for both normal and peak workload conditions.

How are software requirements validated?

It is important to ensure that the requirements for the software system under construction accurately represent not only what the software developers and programmers are building, but also what the customer or client originally desired. Validation is very important, as catching requirement errors early on in the software development lifecycle reduces expense greatly. Rectifying a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.

The IEEE has developed another standard, IEEE 830, for best practices for validating software requirements. The IEEE 830 standard lays out some suggested process improvements and gateways, including:

1. Requirements reviews.

2. Manual systematic analysis of the requirements.

3. Software prototyping.

4. Using an executable model of the system in order to verify the requirements.

5. Test case generation.

6. Developing test cases from the requirements in order to validate that they are in fact testable and verifiable requirements as written.

7. Automated consistency analysis.

What is software requirements modeling?

There are a number of different techniques which can be used to model software requirements. Some of these software requirements modeling techniques I have discussed at length elsewhere in this hub tech insider blog, and some of the other techniques for modeling requirements I will explore in more detail within these pages in future articles. User stories, user goals, use cases, and UML diagrams are some of the techniques oftentimes used to model software requirements, but there are many others including formal methods, natural languages, and structured diagrams.

The reason that modeling techniques are used in addition to prose requirements is that English, or any other natural language, inherently adds difficulty to the process of communicating requirements for the poduction of software. These difficulties can include lack of precision and clarity of language to the improper mixing of functional and nonfunctional requirements. The needless overcomplexity of combining requirements until they no longer make sense, in a wierd amalgamation of needs, is a common problem, as is ambiguity of language.

How do you conduct a requirements elicitation and gathering session?

There are many common problems encountered when elicitating requirements for a software system to be constructed. Requirements elicitation is a process in which requirements engineers or business analysts work with customers in order to determine the proposed system’s operational constraints, services, and application scope. There are many people involved in most requirements elicitation and gathering phases of a software development project, and they are collectively known as project stakeholders. Project stakeholders may include domain experts, managers, engineers, end users, and other internal and external personnel.

One of the primary concerns of the requirements engineer is eliciting requirements from stakeholders who are not sure what it is they really want from the system under discussion. Stakeholders can in fact introduce many serious detrimental issues into the requirements gathering and elicitation process that you should be aware of. These can include expressing requirements in their own, often incorrect terminology, providing conflicting requirements, and the introduction by stakeholders of organizational politics and other bureaucratic externalities which may unduly influence the requirements. It is not at all uncommon for stakeholders to feel free to change the requirements at will in response to new stakeholders who may emerge mid-project, as well as shifting business environments. All of these detrimental factors must be carefully monitored and counteracted by the requirements engineer when necessary.

HubTechInsider.com YouTube Channel

Subscribe to HubTechInsider.com YouTube Channel

SEO Made Easy 2013 FREE Special Report!

PHP for Beginners

Google + Domination for Business

LinkedIn for Business Training Course

Mastering WordPress Video Training Course

Twitter Business Magic Video Tutorial Series

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. I have been working in the software engineering and ecommerce industries for over fifteen years. My interests include computers, electronics, robotics and programmable microcontrollers, and I am an avid outdoorsman and guitar player. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which is  Tshirtnow.net.

What are the qualities of bad software code? How can you tell if your software project has bad code? July 12, 2011

Posted by HubTechInsider in Agile Software Development, Project Management, Software.
Tags: , , , ,
1 comment so far
User:Dreftymac/Docs/ImageDisclaimer

Image via Wikipedia

What are the qualities of bad code? How can you tell if your software project has bad code?

Troubled software projects and bad code are facts of life in the software business. Today’s applications, system software, even embedded and operating systems programming is increasing being outsourced or at least distributed.

The need for being able to quickly evaluate the quality of software code, describe any known issue in simple aterms and then execute on a planned approach to rectify these issues is greater than ever.

A common vocabulary for project teams, refactoring engineers, and project managers and stakeholders is of a fundamental assistance in manageing software development projects.

You may find yourself sitting in a meeting or conference room or perhaps on a conference call with a group of computer programmers who are discussing some sections of code, or if you are particularly unlucky, perhaps an entire application of software development project, that is troubled using some of these below listed terms. After each of these negative, “bad code” terms I have tried to describe what is meant by each of these terms for bad software. After each description, I list the term for the opposite, positive “good code” quality contrary to the bad code quality.

1. Fragility: When changes in the software code cause the system to break in places that have no conceptual relationship to the part that was changed. This is a sign of poor design. The opposite of fragility is known as robustness.

2. Immobility: When the code is hard to resuse. The opposite of immobility is known as re-usability.

3. Needless complexity: When the design is more elaborate than it needs to be. This is sometimes also called “Gold plating”. The opposite of complexity is known as simplicity.

4. Needless repetition: This occurs when cut-and-paste of code segments is used too frequently. The opposite of repetition is known as parsimony.

5. Opacity: When the code is written in such as manner as it is not clear. The opposite of opacity is known as clarity.

6. Rigidity: When the design is hard to change because every time you change something, there are many other changes needed to other parts of the system. The opposite of rigidity is known as flexibility.

7. Viscosity: When it is easier to do the wrong thing, such as a quick and dirty fix, than the right thing. The opposite of viscosity is known as fluidity.

In order for your software development project to feature the opposite, more desirable positive qualities to the ones listed above, your project must exhibit a good software architecture, solid software design, and effective coding practices.

For further reading on this topic, I highly recommend the excellent book by R.C. Martin, “Agile Software Development, Principles, Patterns, and Practices“, Prentice-Hall, Englewood Cliffs, NJ, 2002.

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a Technical PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which are Twitterminers.com and Tshirtnow.net.

%d bloggers like this: