Requirements
Use Prototypes to Verify Application Workflow
June 7, 2011 | 
Author 
The requirements for managing a product or service workflow must be documented. However, when the number of requirements grows and the document becomes lengthy, readers find it difficult to review the entire document. Beyond a certain point, they rarely read the document again completely, or if they do, they skim over important sections without critical analysis.
It is therefore useful to express the requirements as a prototype. Doing so takes several pages of written requirements and represents the content visually in the form of prototype screens. Prototypes themselves can take many forms. A common way is to use HTML prototypes that represent web applications. Some professionals use a drawing program or even regular paper for their sketches. Others like to use Photoshop to mock up a prototype GUI, the advantage being that people will not confuse the prototype with the actual application.
Posted in Enterprise software, Outsourced Product Development, Product Development, Product Engineering, Requirements | 
Tags: HTML prototype, Requirements gathering, User interface, wire frames | 
Comments Closed
Software Development – The problem is of plenty, not scarcity
Software developers often are faced with a bewildering array of choices while developing software. Oftentimes frameworks, tools and technologies are mandated by client organizations to development teams. It is very possible that the team members are not exposed to at least one of the important technologies, tools or frameworks.
In the rush to shorten the learning curve and to get the development completed, very often basic development guidelines for successful development are ignored. Basic principles of object orientation and modularity of code are ignored and several transversal functions are unstated and are not met. This is discovered half way through the development and in order to accommodate various stated and unstated need, the development goals of code quality are almost never met.
Posted in Enterprise software, Outsourced Product Development, Product Development, Product Engineering, Requirements | Tags: Code Modularity, Code Quality, Object Orientation, Scaffolding, Software Architecture, Software Development, Software Development Guidelines, Software Quality | Comments Closed
Implementing agile with distributed teams
Agile works well with small and co-located teams. Does this mean that agile cannot be used for larger enterprises that requires scaling, and in outsourcing engagements? It certainly isn’t the case as distributed teams are deriving value from agile development. Practicing agile in distributed environment is more complex than practicing agile in co-located teams, and it requires a lot of efforts to make this work.
In our experience, when we started making modifications in agile to make it work in distributed environment, we realized that it did offer a lot of benefits. In fact, we have used agile methods even in our professional services engagements with our customers, and it worked famously well. Let me explain the subtle changes that we made to the process and the inherent benefits of this change.
Posted in Outsourced Product Development, Product Engineering, Requirements | Tags: Agile Offshore, Customer Concerns, Distributed Agile, Outsourced Agile | Comments Closed
Suitability of Agile in fixed bid projects
Fixed bid projects are characterized by fixed time, predefined scope and fixed budget. Add to this, predefined quality checks. We will keep quality out of consideration for it can be never be considered a variable. The other three (time, scope and budget) can be considered variables. In most fixed-bid projects, none of them are allowed to be variables, which more often than not, lead to the project not meeting the expectations of stakeholders. Having all three of time, budget and scope fixed is very unrealistic and will most likely result in project failure. However, if we can change one of the variables, it will certainly increase the probability of success.
Posted in Outsourced Product Development, Product Engineering, Requirements | Tags: Agile Development, Agile Outsourcing, Agile Suitability, Fixed Bid, Fixed Bid Projects, Fixed Projects, Product Quality, Scope Creep, Time Budget And Scope, WORKING PRODUCT | Comments Closed
Product Engineering – Aligning customer needs
Whenever we engage with the customer, the most critical aspect will be to align our knowledge with the customer needs. This is especially true and complex, when you are talking about outsourced product development, as we ought to align our knowledge with our customer’s customer needs.
In my mind, product engineering is a domain and expertise by itself as the skills required to build a product are far different from the skills required to build an application. Product is never custom-built for a particular customer; rather it is generic and requires better skills to ensure that the code base is scalable, robust and configurable. Essentially, architecting a product is much different compared to architecting an application.
Posted in Enterprise software, Outsourced Product Development, Product Development, Product Engineering, Requirements | Tags: Customer Feedback, Customer Needs, End-user Needs, outsourced software product development, PRODUCT ENGINEERING, Product engineering services, Product Success | Comments Closed
Software user adoption – Key to business results
I was having a conversation with an enterprise software vendor. He was mentioning that the biggest challenge that he faces is that he is not able to increase the adoption levels of his software and it is costing him dearly. I just casually mentioned to him that the usabiilty of his software should be as simple as using a desktop productivity tool. I am not sure if this got him thinking, but it certainly got me thinking deep about how we do this at Ivesia.
I just broke them down into user adoption challenges and the solution that Ivesia offers. I’ve just reproduced them here.
Challenges
- Enterprises are failing to make best use of the software that they already possess
- User adoption will remain a premium without ease-of-use
Posted in Outsourced Product Development, Product Development, Product Engineering, Requirements | Tags: Business Results, Enterprise Software, Enterprise Software Adoption, Software Adoption, User Adoption, User Adoption Challenges, User Adoption Levels, Web 2.0 | Comments Closed
Prototype Before You Build
Prototyping is one of the most important activities of requirements analysis. Typically when people think of requirements gathering, they think about writing a document. Although writing a formal document is necessary, it is not sufficient to provide non-technical users a good understanding of the product that is being built.
For most web applications, a simple prototype can be easily created using plain old HTML. This will provide the customer with an understanding of the user interface of the application and the workflow of the system. Misunderstandings can be quickly corrected thus putting the requirements on a firmer footing.
Prototypes are usually meant to be thrown away. This means that you don’t have to spend too much time worrying about the source code of the prototype. The visuals and the workflow are what is important. Getting a prototype up sooner saves time in the requirements analysis process and serves as a good foundation for the rest of the project.